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THEME 

Software  Engineering  has  evolved  lapkUy  but  the  gap  between  denumd  and  software  output  continues  to  grow.  By  the  end 
of  the  decade  research  programmes  in  Noith  America,  Europe  and  Japan  will  begin  to  produce  results  in  the  areas  of  software 
tools,  computer  architecture,  etc.  The  symposium  considered  how  th^  advances  might  be  applied  to  the  avionics  systems  of 
the  nineties  and  beyond  and  their  impact  on  our  a^irations  in  areas  such  as  operation,  built  tolerance  etc.  The  software  element  j 

of  modern  weapon  systems  continues  to  grow  in  size  and  complexity;  offering  madr  advantages  but  also  potential  risks.  f 

L’ingenierie  du  logiciel  a  ete  I'objet  dTine  Solution  rapide,  mais  le  fosse  qui  existe  entre  la  demande  et  la  production  de 
logicieb  ne  cesse  de  s’datgir.  A  la  fin  de  la  decennie,  les  programmes  de  recherche  Uncn  en  Amerique  du  Nord,  en  Europe  et 
au  Japon  commenceront  h  donner  des  resultats  dans  le  domaine  des  outils-logiciels,  de  I'archilecture  des  ordinateurs,  etc.  Le 
symposium  a  etudie  la  fa(on  dont  ces  progrbs  pourraient  etre  appliques  aux  systemes  d'avionique  des  annees  90  et  au.delb  ainsi 
que  leur  impact  sur  nos  aspirations  d^  des  domaines  tds  que  la  fhcilite  de  mise  en  oeuvre,  I’insensibilite  aux  defaillances,  etc. 

I  .'element  logiciel  des  systemes  d'armes  modemes  ne  cesse  de  grandir  en  taille  et  en  complcxitc,  en  presentant  dcs  av  anlagcs 
importants,  mais  aussi  des  risques  potentiels. 
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TECHNICAL  SUMMARY 
SSth  MEETING  OF  THE  AVIONICS  PANEL 
ON 

•SOFTWARE  ENGINEERING  AND  ITS  APPUCATION  TO  AVIONICS” 
by 

D.V.Gaggiii 

Director,  US  Army  Avionics  R  &  D  Activities 
AtmSAVAA-DD 
Fort  Monmouth  N  J.  07703-5401 
United  States 


The  symposium  was  judged  by  the  panel  members  to  be  extremely  successful.  The  large  majority  of  papers  were  of  a 
high  quality,  the  attendance  was  excellent  throughout  the  meeting  and  the  audience  participation  was  exceptionally  good. 
Several  key  points  were  continuously  brought  out  and  are  worth  highlighting  here. 

The  development  process  can  be  represented  as  a  water  wheel  whereby  the  user  needs  become  the  system  requirements 
which  become  software  requirements  which  are  implemented  in  code,  etc.  until  a  final  product  is  delivered  back  to  the  user. 
This  process  takes  many  years  and  involves  bundles  of  people  even  for  the  simplest  systems.  Any  misunderstanding  along 
the  way  is  carried  through  to  the  end  item.  It  is  imperative  that  the  key  individuals  in  the  chain  have  direct  access  to  the  user 
and  completely  understand  the  original  user's  need. 

Ada  will  be  the  standard  higher  order  language  of  the  near  ftiture.  The  Ada  deveicqtment/support  environment  is 
expanding  rapidly  but  needs  maturity  before  it  receives  wide  acceptance.  Ada  will  not  solve  all  higher  order  language 
problems  and  will  continue  to  evolve  as  more  people  use  and  become  familiar  with  it.  But,  like  any  standard,  it  is  a  snapshot 
in  time  and  will  be  replaced  by  far  more  advanced  systems  such  as  GRAPH.  These  new  languages  are  not  in  conflict  with 
Ada  but  a  natural  technology  evolution. 

Documentation  is  a  major  concern.  It  is  expensive  to  generate,  time  consuming  and  since  it  is  by  definition  one  of  the 
last  functions  to  be  complete  in  the  development  phase  it  is  one  of  the  easiest  things  to  eliminate  when  a  program  runs  into 
hmding  difflculties.  But  since  documentation  is  critical  during  the  operation  and  support  phase,  we  must  place  greater 
importance  on  it  during  development. 

Expert  systems  are  beginning  to  emerge  and  appear  to  be  extremely  useful  in  coping  with  our  increasingly  complex 
systems.  Initial  application  will  probably  be  concentrated  in  ground  support  systems  and  ILS  tools  before  maturing  into 
prime  mission  equipment.  True  artificial  intelligence  is  still  in  the  research  stage  with  no  near  term  applications  foreseen. 

Advances  in  software  technology  are  being  exceeded  by  the  rate  of  growth  in  avionic  application.  Major  efforts  are 
mandatory  to  improve  software  technology.  For  example,  innovative  techniques  are  required  to  permit  reusable  software; 
integrated  tools  are  needed  to  allow  automatic  software  production  in  order  to  increase  productivity. 

Software  reliability  has  become  an  important  issue  in  mission  safety  critical  avionic  systems.  Fault  tolerance  techniques 
and  methodologies  are  being  developed  to  address  this  issue. 

Integrated  Programming  Support  Environments  are  not  now  available  but  are  badly  needed  and  slowly  being 
developed. 

Design  methods  still  tend  to  be  non-standard  but  Ada  is  pushing  more  and  more  designers  towards  an  object  oriented 
approach. 

Finally,  requirements  deflnitions  which  historically  have  used  natural  language  appear  to  be  tending  towards  more 
formal  approaches  such  as  structured  analysis.  Even  diough  these  methods  are  more  rigorous  this  will  be  slow  in  coming  due 
to  reduced  readability. 
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ADA  THE  SOfTWARE  ENGINEERINC  TOOL  FOR  AVIONICS 
KEVNOTE  ADDRESS 

by 

J.Balz 

ADA  Joint  Program  Office 
Rm  jE  1 1.  The  Pentagon 
Washington  D  C.  2U30I 
USA 


The  text  of  this  address  was  not  available  at  the  lime  of  printing. 


DISCUSSION 


W.ManML  Ge 

1 .  Missile  software  is  divided  into  two  parts;  guidance  software  located  within  the  missile  and  management  software 
located  on  the  aircraft.  Does  CAMP  address  both  parts? 

2.  Is  CAMP  available  outside  US? 

Author’s  Reply 

1 .  CAMP  software  is  grouped  into  general  and  non-general  classifications.  It  is  my  understanding  that  the  general 
parts  perform  support  fimetions  which  are  applicable  to  a  wide  variety  of  real-time  applications,  whereas  the  “non- 
general"  parts  are  associated  specifically  with  missile  avionics  functions  which  are  common  among  many  missile 
systems.  Intuitively,  I  believe  tlut  the  laner  could  include  functions  like  navigation,  guidance  and  perhaps  power 
management.  But  it  is  less  clear  that  detailed  functions  associated  with  flight  control  can  be  made  common,  since 
each  missile  system  will  have  its  own  unique  set  of  control  surfaces,  propulsion  systems  and  attitude  control 
thrusters,  etc.  I  will  tty  to  provide  more  detailed  information  on  the  actual  parts  being  developed  under  the  CAMP 
project. 

2.  I  am  hopeful  that  at  least  a  reasonable  level  of  detail  on  the  CAMP  software  parts  can  be  provided.  I  am  uncertain 
what  level  of  information  can  be  provided  outside  the  US  and  therefore  do  not  know  if  the  Ada  source  code  can  be 
provided. 


D.Gaaifai,US 

Many  people  are  concerned  about  using  Ada  on  large  software  development  projects  because  of  the  lack  of  software 
tool  maturity.  What  is  the  track  record  of  such  programs  as  far  as  keeping  within  cost  and  schedule  predictions? 

Author’s  Reply 

I  do  not  hcive  any  information  on  track  records  for  programs  employing  Ada.  However,  the  maturity  (and  quality)  of  the 
software  tools  available  is  strictly  a  function  of  the  particular  compiler  and  support  system  vendor  chosen.  That  choice 
is  inherently  related  to  the  target  processors  to  be  employed  in  the  real-time  system.  The  choice,  therefore,  must  be 
made  in  a  coordinated  way.  If  the  target  processor  choice  is  made  without  regard  to  the  compilers  and  tools  available  to 
support  software  impfememation  for  the  target  processors,  then  the  program  managers  are  choosing  a  high  risk 
approach.  The  Ada  Compiler  Evaluation  Capability  (ACEC)  sponsored  by  the  AJPO  is  an  effort  to  help  program 
managers  make  wise  choices  in  this  area. 


J,Lacroh;,Fr 

What  improvements  in  Ada  real-time  performance  do  you  expect  ftom  the  new  tools? 

AuIIim’s  Reply 

I  do  not  see  new  tools  as  improving  Ada  real-time  perfbrmaiKe,  but  as  reducing  the  time  and  cost  lor  development  and 
maintenance. 

The  improvement  in  real-time  performance  will  be  a  function  of  several  other  actions;  (I)  The  improvement  of 
compilers  to  produce  more  efficient  target  code,  (2)  Improvement  of  run-tiine  opetatiiy  systerro  and  (3)  The 
improvement  of  target  processors  for  reabtiine  control  operation.  It  would  be  best  for  these  actions  to  be  taken  in  a 
highly  coordinated  manner,  but  they  will  be  done  largely  by  different  sets  of  people  for  different  motivations. 
Furthermore,  the  actions  needed  may  differ  from  comf^er  to  compiler,  from  machine  to  ttuchine  and  run-time 
operating  system  to  run-time  operating  system.  In  addition,  modest  changes  to  the  Ada  language  itself  may  come  about 
in  the  next  few  years  to  enable  a  better  coupling  between  Ada  constructs  design  explicity  for  real-time  applications  and 
machine  characteristics  needed  for  efficient  real-time  control  operation. 


Haasures  of  Harlt  for  Advanced  Hilitacy  Avionlcai 
A  Uaera'  Perapectlve  on  Software  Utility 
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M»ior  Hark  C.  Dickerson,  Bxperiaental  Test  Pilot,  P-16  Coabined  Test  Force 
Hr.  Victor  H.  LaSaxon,  Hanager-Aircraft  Flight  Test  Engineering  (ETSS) 

Ccaputer  Sciences  Corporation 


6S10th  Test  Ming 

Edwards  AFB,  California  93523-5000 


SUHHARY 

This  paper  is  Intended  to  provide  recoaaendatlons  for  inproving  the  software 
developsient  process.  The  recosnendations  are  the  result  of  discussions  with  F-15,  F-16, 
and  HH-60  test  pilots,  navigators,  and  flight  test  engineers.  Because  today's  aircraft 
are  beconing  so  software  intensive,  and  because  the  development  process  is  so  involved, 
users  and  developers  must  redouble  efforts  to  design  systems  correctly  the  first  time. 

Although  29  specific  recommendations  are  given,  they  can  be  boiled  down  to  four 
general  guidelines: 

A.  Keep  switch  actions  to  a  ninimum. 

B.  Keep  switchology  consistent, 

C.  Teilor  displays  by  flight  phase,  but  keep  other  options  visible. 

D.  HOST  IHPORTANT,  carefully  process  and  meter  the  infoirmation  presented  to  avoid 
pilot  overload. 

NOTE:  Annotatlona  of  the  form  (R17)  appear  throughout  the  text.  They  refer  to  specific 
recommendations  listed  in  the  last  section  of  the  paper.  In  this  case  (recommendation  17.) 


TODAY'S  SYSTEMS 

Today's  aircraft  rely  heavily  on  software  intensive  advanced  avionics  systems  (See 
figure  1).  Indeed,  the  importance  of  this  is  evidenced  by  the  fact  that  many  modern 
fighters  undergo  planned,  deliberate  software  and  hardware  evolutionary  steps.  The  F-IS 
and  F-lt  multistaged  Improvement  programs  (MSIP)  are  examples  of  this.  Specifically, 
HcDonnell  tkMglas  Corporation's  Pace  Eagle  and  Advanced  Hornet  programs  are  seeking  to 
define  future  changes  in  the  P-IS  and  F-18  so  as  to  keep  the  aircraft  operationally 
competitive  against  the  evolving  threat.  These  programs  have  sought  to  group  upgrades  in 
an  orderly  and  planned  fashion. 

The  F-18  ettack  capability  improvement  will  be  one  area  that  will  encompass  s  great 
deal  of  advanced  evlonlcs  software.  This  softwere  will  be  designed  so  as  to  use  and 
integrate  the  functions  of  new  equipment  such  as  the  Flight  Incident  Recorder  and 
Honltoring  Systox  (FIRAHS),  a  built-in  test  and  health  monitoring  system  that  is  an 
improvement  on  the  current  maintenance  signal  data  recording  system  the  AIM-120  advanced 
medium  range  air-to-air  missile  (AHRAAN),  an  airborne  self-protection  jammer  and,  of 
course,  the  ACH-CSF  alr-to-surfaee  imaging  Infrared  Maverick  missile.  Other  planned 
Improvements  that  will  require  a  large  eoftware  role  is  the  addition  of  a  Hughes  forward- 
looking  infrared  (FLIR)  navigetion  system  for  enhanced  night  attack  capability,  raster 
head-up  (RDO)  display  and  night  vision  goggle  compatibility. 

Possible  additions  to  the  F-15  include  new  weapons  systems,  electronically  scanned 
antennas  for  the  radar  and  new  sensing  systems  such  ss  infrared  sensors.  The  F-15E 
progrsm  is  equally  as  active  in  the  edvenced  evlonlcs  softwere  arena.  HcDonnell  Douglas 
is  adding  night,  all-weather  strike/attack  capability  to  the  already  advanced  F-15  Eagle. 
It  will  have  double  the  central  computer  capability  in  the  same  sixe  box  as  that  of  the 
first  production  HSIP  aircraft.  The  APG-70  radar  capability  in  the  F-15E  has  a  512- 
kilobyta  capacity.  This  is  a  significant  increase  from  the  AFG-63  384K  capacity. 

The  General  Dynamics  F-16  multinational  staged  improvement  program  goes  back  to  1979, 
and  like  the  F-15  and  F-18  programs,  it  is  very  dependent  on  advanced  avionics  software. 
Block  40  aircraft  will  have  a  primary  niaalon  role  of  night,  low  altitude  precision 
strike  under  adverse  weather  conditions.  Computer  Sciences  Corp.  is  aiding  the  Air  Force 
in  integration  and  flight  test  of  all  F-16  HSiP  avionics  including  the  Martin  Marietta 
low  altitude  navigation  and  targeting  Infrared  for  night  (LANTIRH)  pod  system  as  well  as 
the  Rockwell  Collins  global  positioning  system  (GPS)  for  very  precise  position,  velocity 
and  time  information.  The  Block  40  aircraft  will  also  contain  a  number  of  specific 
software  enhancements  so  as  to  Improve  pilot-vehicle  Interface.  A  Teledyne  general 
avionics  computer  (BhC)  will  replace  the  present  fire  control  computer.  This  computer 
contains  four  times  the  memory  and  three  times  the  computational  capability  of  the  current 
P-16C/D  versions.  Rsdio  frequsncy  compatibility  will  be  totally  software  programmable  on 
Block  40  aircraft  with  the  implamontatlon  of  an  advanced  interference  blanker  unit.  It 
will  accommodate  up  to  six  matrices  of  actions  to  be  taken. 

Nithin  the  program.  General  Dynamics  Ft.  Worth  Division  is  also  working  on  the 
configuration  and  avionics  of  the  Block  50  aircraft.  Ttwse  changes  resulted  from  a  joint 
General  Dynamics  Defense  Department  emerging  threats  study.  Upgrades  will  be  designed  to 


improve  alr-to*-alr  arena*  to  add  more  advanced  night  and  day  awareness 
and  threat  systems  to  counter  the  Soviets*  look-down,  shoot-down  radar  capabilities, 
and  to  continue  efforts  to  make  the  pilot's  job  easier  and  more  efficient. 


TOMORROW’S  SYSTEMS 

The  current  crop  of  avionics  software  available  to  the  aviator  provides  a  virtual 
avalanche  of  "data*  or  "facts"  suitable  for  analysis  and  interpretation.  The  next 
generation  of  pilot  aids  will  advance  from  this  "data"  oriented  software  to  an 
"information"  network  displayed  to  the  pilot  at  the  appropriate  time  or  available  on 
demand  (see  figure  2).  We  are  currently  witnessing  the  evolutionary  process  taking 
place.  For  instance,  although  altitude  is  displayed  on  the  HUD,  some  fighter  aircraft 
have  the  added  feature  of  a  "break  X"  low  altitude  cue  as  well  as  an  audible  "PULL  UP" 
command  from  the  c<xnputeri2ed  voice  generator.  The  critical  difference  between  data  or 
fact  oriented  software  and  more  "information  oriented"  software  is  the  interpretive 
element  of  the  algorithms.  The  future  software  package  will  be  designed  to  help  the 
pilot  maintain  timely  and  effective  situational  assessment.  The  system  will  act  to  a 
great  degree  as  an  extension  of  his  senses  and  perceptions.  it  will  also  provide 
sufficient  automation  to  manage  certain  subsystems.  ‘Hiis  will  allow  the  pilot  to  maintain 
the  "big  picture"  and  not  be  distracted  by  mundane  simple  tasks.  This  should  result  in 
improved  pilot  response  time,  particularly  during  heavily  tasked,  high  stress  and/or  high 
threat  situations,  integration  of  sensors,  flight  control,  fire  control,  countermeasures 
and  weapons  with  a  beyond-visual-range  capability  will  provide  the  pilot  situational 
awareness  capabilities  designed  to  increase  his  ability  to  assess,  accurately  monitor  and 
quickly  react  to  the  tactical  situation.  Furthermore,  with  this  advanced  software,  the 
system  will  be  able  to  incorporate  tactical  information  from  airborne  or  land  based 
integrated  battle  management  command  posts. 

Several  software  types  will  be  used  to  accomplish  the  goal  of  subsystems  management, 
enhanced  beyond  visual  range  capability,  and  situational  assessment,  and  display.  These 
include  three  dimensional  color  graphics  drivers,  speech  recognition  and  synthesis  routines, 
multisensor  image  recognition,  basic  system  software,  as  well  as  software  for  weapons 
delivery.  The  situation  assessment  software  will  be  designed  to  integrate  multiple 
sensor  inputs  from  onboard  as  well  as  from  data  linked  sources  if  available.  Once  enough 
information  has  been  assembled,  these  elements  may  even  provide  the  pilot  with  beyond- 
visual-range  identification  information.  The  system  would  then  establish  the  magnitudes 
and  immediacy  of  threats,  storing  the  data  In  memory  and  alerting  the  pilot,  programs 
will  focus  on  the  Integrated  attack  scenario  and  will  display  engagement  options  that 
also  include  maintaining  combat  flight  integrity.  The  ultimate  objective  is  to  optimize 
attack  opportunities  for  the  flight  while  minimizing  risk  exposure. 

As  the  Information  is  accumulated,  it  will  be  prioritized  and  displayed  in  a  manner 
so  as  not  to  overload  or  distract  the  pilot.  One  concept  being  developed  would  use  a 
miniature,  helmet-mounted  television  display.  Avionics  software  would  command  symbology 
showing  the  location  of  both  airborne  and  land  based  threats.  Additionally,  the  display 
would  indicate  weapon  status  and  modes  as  well  as  the  position  of  friendly  forces.  The 
concept  also  includes  a  sophisticated  array  of  sounds  and  verbal  cues  that  could  alert 
the  pilot  to  threats  at  his  six  o'clock  position  as  well  as  indicating  his  own  flight 
conditions.  All  of  these  informational  displays  will  be  flexible  and  fully  programmable 
by  type  mission  and  pilot  preference.  The  pilot  will  be  able  to  see  any  sensor  Information 
superimposed  over  the  entire  field  of  view  or  a  selected  portion,  in  addition,  the  pilot 
will  have  infrared  imaging,  a  large  menu  of  navigational  aids  and  the  ability  to  magnify 
an  area  of  particular  interest. 

Mode  selections  and  commands  will  be  designed  so  as  to  reduce  pilot  workload.  Flight 
gloves  may  be  equipped  with  magnetic  location  devices  so  as  to  allow  the  pilot  to  request 
information  by  pointing  his  finger.  Also,  there  may  be  a  limited  ability  to  employ  voice 
commands. 


THE  ACQUSITION  PROCESS 

As  might  lv>  expected,  the  process  for  acquiring  new  software  systems  like  these  is 
usually  lengthy.  Figure  3  shows  the  major  steps  in  the  USAF  acquisition  chain.  This 
process  can  take  in  excess  of  three  years  for  a  software  design  change  on  a  mature  system. 
It  is  even  longer  for  a  new  system.  The  portions  of  this  process  where  the  software 
engineer  has  the  greatest  c^portunity  to  Influence  the  results  are  in  the  design  and 
design  review  phases.  Unfortunately,  pilot  input  to  the  product  traditionally  occurs  as 
part  of  the  Statement  of  Need  (long  before  the  engineer  begins  a  design),  at  the  design 
reviews  (by  which  time  the  design  Is  virtually  complete),  and  during  flight  test  (which 
is  a  very  expensive  way  to  find  problems). 

The  problems  with  this  should  be  obvious.  There  are  several  levels  between  the 
Initial  pilot  Inputs  and  the  Initial  design  effort.  Close  scrutiny  will  reveal  that 
although  some  of  the  people  Involved  at  these  levels  are  engineers,  few  are  likely  to  be 
pilots.  In  fact,  most  of  then  will  be  in  marketing,  contracting,  or  public  relations. 
These  people  may  have  no  clue  what  the  pilot  wanted,  nor  what  kind  of  software  effort 
will  be  needed  to  provide  it.  They  know  neither  the  software  engineer's  job,  nor  the 
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pilot's*  yet  they  are  the  channel  through  which  the  pilots'  requests  oust  flow  in  order 
to  get  to  the  software  engineer. 

The  designer  and  the  pilot  must  make  an  effort  at  the  start  of  design  work  to  talk 
face  to  face  and  work  shoulder  to  shoulder*  They  must  be  sure  that  what  is  being  developed 
is  what  the  user  really  requested.  (R18)  They  must  also  work — sometimes  at  odds*‘*'to  be 
sure  that  what  users  have  requested  is  what  they  really  need.  To  this  end,  Northrop  Corp 
used  pilot  "murder  boards"  during  P->20  software  development.  These  groups  of  experienced 
pilots  would  discuss  employment  concepts,  hammer  out  a  unified  position,  and  submit  it 
directly  to  the  software  engineers,  with  virtually  no  middlemen  involved.  Ihe  Air  Force 
test  pilot  felt  the  results  were  excellent. 

The  Users'  Groups  and  Cockpit  Review  Teams  which  are  listed  in  the  figure  deserve 
elaboration.  These  groups  normally  consist  of  a  handful  of  highly  experienced,  highly 
respected  pilots.  These  individuals  are  delegated  the  authority  to  speak  for  large 
numbers  of  pilots  in  their  respective  services  or  countries,  and  they  usually  have 
sufficient  backing  to  make  their  opinions  stick.  These  users  will  discuss  potential 
mechanizations,  evaluate  contractor  proposals,  and  vote  on  what  they  feel  will  be  the 
best  approach  to  a  given  problem.  Normally  the  results  of  these  votes  will  form  the 
basis  for  a  contract  to  modify  a  current  software  package,  or  to  design  a  new  one. 

Often  members  of  the  Users'  Group  will  attend  the  preliminary  or  critical  design 
reviews  to  confirm  that  the  system  looks  the  way  they  expected  it  to  look.  Having  a 
simulation  available  for  pilot  evaluation,  even  a  rudimentary  one,  can  do  a  lot  to  confirm 
the  accuracy  of  the  mechanization  before  the  more  costly  flight  testing  phase.  (R*>19) 
When  these  simulations  are  used,  the  actual  code  that  will  support  the  aircraft  itself 
should  be  used  if  at  all  possible.  This  not  only  saves  work  for  the  programmer,  but  it 
gives  the  pilot  a  chance  to  see  the  "real  thing"  to  the  maximum  extent  possible.  (R-20) 
It  may  also  give  the  software  designer  the  leverage  to  push  for  earlier  hardware 
development  so  that  it  can  be  evaluated  along  with  the  software. 

When  simulation  is  performed,  every  effort  should  be  made  to  design  some  quantitative 
form  of  evaluation  into  the  simulation.  Many  decisions  are  made  simply  on  the  basis  of 
what  a  certain  pilot  "likes"  or  "dislikes".  In  these  cases,  the  more  forceful  or 
authoritative  pilots  may  tend  to  sway  other  evaluators  based  solely  on  strength  of 
personality.  If  very  specific  tasks  are  laid  out— the  CORRECT  tasks— then  there  will  be 
little  room  for  argument.  Being  able  to  tnrite  that  "Nechanization-'B  had  a  301  lower 
average  time  required  for  accomplishing  the  task,"  makes  the  results  difficult  to  argue 
with.  (R-21) 


F-15  PILOT  COMMENTS 

The  F«15  is  a  two*"engine,  all'*weather  fighter-interceptor  built  by  McOonnell-Douglas. 
Originally  designed  primarily  for  the  air*to~air  role,  the  aircraft  has  subsequently  been 
modified  to  perform  the  all-weather  long-range  interdiction  mission  as  well  (F-15E).  It 
has  also  been  selected  as  a  technology  demonstrator  for  advanced  short  takeoff  and  landing 
(STOL)  concepts. 

P-15  pilots  and  weapon  system  officers  (WSOs)  fauniliar  with  all  of  these  variants 
were  asked  to  evaluate  how  effectively  the  avionics  and  software  support  their  missions. 
The  evaluators  were  all  members  of  the  P-15  C<mbined  Test  Force  at  Edwards  AFB,  California. 
To  simplify  discussion,  we  have  broken  the  mission  down  into  the  Pre-takeoff,  Cruise, 
C<»nbat,  and  Recovery  phases.  Surprisingly,  a  large  proportion  of  aircrew  comments  related 
to  the  Pre-takeoff  phase.  This  is  probably  because  that  is  the  phase  in  which  the  moat 
interaction  with  onboard  computers  takes  place — data  is  going  from  the  crew  to  the 
aircraft.  Keep  in  mind  that  most,  if  not  ail,  problem  areas  discussed  here  will  have 
been  corrected  by  the  time  the  systems  are  fielded.  Our  objective  is  to  avoid  tripping 
over  the  same  problems. 

In  any  advanced  multirole  aircraft  like  the  F-15E  (figure  4),  a  lot  of  keyboard  work 
is  required  to  set  up  all  the  systems.  It  should  be  no  surprise  that  pilots  prefer 
automated  data  entry  during  the  Pre-takeoff  phase.  (R2)  During  the  remainder  of  the 
flight,  data  goes  both  ways,  but  the  majority  of  the  information  flow  is  from  the  aircraft 
to  the  crew,  so  displays  tend  to  dominate  the  discussion. 

PRE-TAKBOPP:  Although  menu-driven  software  is  generally  preferred,  some  testers 
felt  that  the  weapons  loading  menus  in  the  F-15  could  be  improved.  Pilots  reported  that 
it  was  unnecessarily  difficult  to  change  from  a  branch  entered  in  error  and  get  back  to 
the  correct  branch.  They  felt  that  a  single  action  "Home"  button  would  allow  them  to 
quickly  abort  and  restart  a  transaction  when  loading  weapons.  (Rl)  They  also  noted  that 
two  different  menus  had  very  similar  names,  making  it  even  more  likely  that  an  error 
might  occur.  Specifically,  one  page  was  labeled  "ARMNT",  the  other  was  "WPN".  The  ARHNT 
page  was  the  page  required  to  load  stores  into  inventory,  but  because  of  similar  names, 
it  was  easy  to  Inadvertently  select  the  page  instead.  The  WPN  page  was  actually 
video  select  for  an  electro-optical  weapon.  What  also  annoyed  them  was  that  this  option 
appeared  even  if  no  such  weapon  was  loaded.  The  computer  was  "knowingly*  presenting  an 
option  tht  didn't  exist.  (R3,  R4) 

One  pilot  felt  that  there  were  actually  several  unnecessary  branches.  There  was  one 
branch  for  loading  air-to-ground  weapons,  another  for  air-to-air,  and  yet  another  for 
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*8iBulated*  ^dnance.  Thia  pilot  made  the  point  that  the  aircraft  has  only  so  many 
stations.  HhiT  should  he  need  to  change  loading  modes  and  work  down  through  another 
decision  trs«  when  all  he  really  wants  to  do  is  load  another  station?  Also*  instead  of  a 
special  ^training"  branch*  why  not  just  allow  loading  of  zero  quantity?  This  could  flag 
it  as  a  siaulated  load  and  eliminate  the  need  for  a  separate  branch.  Another  pilot  noted 
that  sosM  options  required  a  "select**  followed  by  "enter”*  others  required  only  a  "select". 
A  conaiatant  technique  would  be  better.  (R7) 

Although  loading  nodes  showed  room  for  improvement*  pilots  praised  the  ability  to 
pre-load  several  different  weapon  delivery  programs.  The  ability  to  quickly  select  the 
desired  program  then  allowed  rapid  reaction  to  pop'-up  targets  once  in  combat,  and  the 
correct  delivery  mode  was  only  one  switch  away.  One  pilot  suggested  that  the  same  ability 
should  exist  for  stores  jettison  modes*  so  that  he  could  quickly  select  any  of  several 
combinations  of  ordnance  and/or  tanks  to  leave  the  aircraft.  (R12) 

In  the  P~15E*  an  up  front  control  panel  was  added  to  make  systems  easier  to  access. 
Although  the  idea  itself  was  appreciated*  some  crewmembers  felt  that  the  mechanization 
required  too  many  pages  of  submenu  to  reach  the  desired  systems.  Regularly  used  systems 
should  have  easily  accessible  menu  pages.  (R17) 

One  last  comment  on  Pre-takeoff  procedures  involved  the  radar.  It  seems  that  the 
system  would  always  power  up  in  a  certain  mode*  no  matter  what  mode  the  pilot  may  have 
selected  on  the  control  panel.  This  would  require  that  the  mode  be  recycled  to  achieve 
the  requested  configuration.  It  isn't  unreasonable  for  a  system  to  require  a  certain 
mode  in  the  early  or  warm-up  phase;  however*  when  the  wam-up  is  ccxnplete  the  system 
should  align  Itself  with  what  the  user  has  requested.  On  an  air-to-air  alert  scramble, 
possibly  air  base  defense*  the  pilot  should  be  able  to  set  up  his  cockpit  so  that  no  more 
than  two  switch  actions  are  required  to  put  a  missile  in  the  air.  He  shouldn't  have  to 
waste  two  actions  just  getting  a  system  to  do  what  he  has  already  directed  it  to  do.  (R9) 

CRUISE/COHBAT:  Although  it  is  admittedly  a  hardware  oriented  item*  a  mandatory 
requirement  for  any  interdiction  aircraft  is  an  intelligent  autopilot.  (R5)  Specifically* 
the  INS  is  programmed  with  route  information.  The  autopilot  can  fly  the  aircraft.  Both 
systems  are  on  the  aircraft  data  bus.  There  is  no  reason  why  the  aircraft  shouldn't  be 
able  to  proceed  autonomously  to  the  target.  Hidden  in  this  requirement  Is  the  need  for 
high  reliability  in  any  software  which  is  coupling  into  the  flight  controls.  At  low 
level*  in  the  weather*  there  la  little  margin  for  error  when  the  aircraft  begins  its  own 
turn  to  the  next  point  on  the  route. 

A  common  thread  among  several  pilots  was  the  concern  for  information  management.  We 
have  aircraft  with  multiple  sensors  and  integrated  avionics.  These  sensors  have  ability 
to  acquire  much  more  data  than  ever  before.  Unfortunately*  human  input  ports  and  maximum 
throughput  rates  have  changed  little.  We  must  be  selective  in  what  we  choose  to  display* 
and  be  sure  that  it  is  displayed  clearly*  Eor  example*  aircrew  were  very  enthusiastic 
about  the  Tactical  Situation  Display.  It  provides  a  moving  map  showing  own  ship  position* 
as  well  as  locations  of  airborne  targets  acquired  by  various  aircraft  sensors.  The 
"God's  Eye*  view  was  considered  easy  to  use  and  interpret. 

On  the  other  hand,  some  crewmembers  were  disappointed  in  the  use  of  new  multicolor 
displays  in  the  weapons  management  mode.  The  capabilities  seemed  to  be  underutilized. 
Instead  of  drawing  in  weapons  and  using  the  various  colors  to  highlight  weapon  status* 
the  same  old  monochromatic  abbreviations  were  used  as  before.  This  forced  the  pilot  to 
come  inside*  focus*  read,  and  interpret— wasting  time.  (R6)  Although  these  displays  have 
limitations  relating  to  glare*  color  washout*  and  resolution*  they  do  have  advantages 
upon  which  we  can  capitalize.  <R6) 

Pilots  were  also  disappointed  with  a  complex  P-15A  radar  display.  The  radar  attempted 
to  present  so  much  data  about  each  target  that  it  became  too  cluttered  to  use  against 
large  formations.  The  symbols  were  large*  each  extending  almost  1/4  of  the  length  of  the 
screen.  When  targets  began  to  maneuver,  one  pilot  described  the  result  as  looking  like  a 
sword  fight.  This  display  may  have  been  a  result  of  the  tendency  to  make  "evolutionary" 
or  Incremental  Improvements  to  systems  and  displays  without  considering  their  effect  on 
the  system  as  a  whole.  Usually  it  is  easier  to  add  code  to  an  operational  flight  program 
(OFF)  than  it  is  to  improve  the  code  that  is  already  there.  This  is  the  beginning  of 
information  overload.  (R13) 

As  users  and  developers,  we  must  be  smart  about  how  much  information  we  display*  and 
about  what  Is  presented  in  the  heat  of  battle.  For  example,  one  pilot  commented  that 
during  the  final  stages  of  an  engagement*  his  primary  concern  is  whether  or  not  he  has 
reached  valid  shot  parameters.  He  felt  that  a  "shoot”  cue  should  stand  out  from 
everything  else,  even  if  your  head  is  out  of  the  cockpit.  Current  "shoot  cues"  may 
actually  be  a  step  backward  from  those  employed  in  later  models  of  the  P-4,  simply  because 
they  are  so  small.  (RIO)  This  small  size  may  be  a  direct  result  of  trying  to  put  too 
much  data  on  the  available  displays,  or  it  may  be  because  the  displays  are  not  properly 
"mlssionized*  to  take  into  account  pilot  workload  as  a  function  of  phase  of  flight. 

One  way  to  take  the  onus  off  of  the  designer  regarding  what  and  how  much  to  present 
is  to  make  displays  more  "tallorable” •  If  the  pilot*  via  automated  data  transfer  equipment* 
can  personally  tailor  his  displays  prior  to  flight  as  a  function  of  flight  mode*  he  can 
find  the  combination  which  works  best  for  his  own  mission  and  experience  level.  Tliis 
"tallorabllity*  doesn't  have  to  be  unlimited.  Just  offering  a  choice  of  several  optional 
chunks  of  information  can  go  a  long  way  toward  making  a  single  OFF  do  the  work  of  several. 
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(R12)  In  the  saae  veini  the  pilot  shouldn't  be  denied  access  to  infornation  which  is 
readily  available  to  the  coaputer.  One  pilot  ccaplained  that  certain  radar  failure 
states  are  accessible  on  the  ground,  but  are  unavailable  once  he  is  airborne.  Nothing  is 
■ore  annoying  than  to  be  denied  Infonsatlon  by  your  own  coaputer.  (Rll) 

RBCOVBRyi  Pilots  were  very  iapressed  with  the  Klopstsin  fornat  landing  display 
planned  for  the  STOL  deaonstrator .  In  this  display,  the  runway  is  represented  by  a 
trapezoidal  figure  displayed  in  the  HUD.  This  figure  has  the  saae  relative  size  and 
shape  as  the  runway  would  if  it  were  visible.  (See  figure  5.)  A  picture  is  still  worth 
a  thousand  ifords.  (R6) 


HH-60  PILOT  COMMENTS 

The  HH-60A  (Night  Hawk)  is  a  twin-turbine  engine,  single-rotor,  seaiaonocoque 
fuselage,  rotary  wing  aircraft,  built  by  Sikorsky.  It  is  designed  for  search  and  rescue. 
With  two  flight  deck  crew  it  is  able  to  carry  up  to  tan  passengers  and  a  crew  plus 
internal  and  ezternal  cargo.  The  cockpit  (figure  6),  designed  by  IBM,  is  highly  integrated 
so  that  the  aircraft  can  be  operated  without  a  flight  engineer.  Features  include  a 
three-cue  flight  director  function,  an  alert  by  ezception  philosophy,  and  coaputer 
nonltoring  of  nomally  static  engine  and  alrfrase  instrunents.  It  also  has  autonatlc 
initialization  of  sost  avionic  control  functions  with  default  values  that,  once  altered 
during  the  slsaion,  resaln  that  way.  (R14)  The  HH-60  also  has  a  flight  planning  software 
function,  fuel  and  power  nanageaent  ccaputer  calculations  and  integrated  basic  flight 
instrunentation  on  multipurpose  displays  (MPD). 

We  solicited  pilot  consents  from  individuals  familiar  with  HB-SO  flight  test  results. 
In  general,  they  concurred  that  the  avionics  software  as  designed  was  suitable  for  the 
mission.  They  were  cosiplenentary  about  the  numerous  options  available  to  the  pilot 
although  there  were  some  minor  deacrepancies  with  the  choice  and  consistency  of  some  of 
the  nomenclature.  (R7)  The  two  major  complaints  concerning  the  avionics  were  the  fact 
that  they  felt  overwhelmed  with  information  and  that  the  system  definitely  was  not  user 
friendly.  Since  there  was  so  much  data  available  there  were  many  layers  of  software  the 
crew  had  to  travel  through  to  get  to  what  was  desired.  A  colorful  ezample  that  illustrates 
this  concerned  the  fifteen  steps  it  took  to  set  the  altimeter  which  could  then  only  be 
displayed  by  going  three  pages  deep  into  the  software.  The  initialization,  recovery,  and 
system  status  monitoring  (IRtSSM)  function  is  the  backbone  of  the  avionics  system.  It  is 
designed  to  perform  initialization  and  monitoring  of  all  avionics  subsystems  as  well  as 
redundancy  control  of  the  avionics  and  pilot  interfaces.  System  Initialization  was 
satisfactory  as  demonstrated  in  196  flights.  This  allowed  the  operator  to  power  up  the 
avionics  and  begin  normal  operations  generally  without  manual  initialization  of  any 
avionics  subsystem.  The  pilots  would  have  liked  the  system  embellished  with  the  capability 
to  cartridge  load  mission  specific  information  and  parameters.  They  felt  that  the  quick 
response  search  and  rescue  role  would  be  enhanced  by  freeing  the  pilots  from  having  to 
load  all  of  the  Information  manually.  (R2) 

Avionics  subsystem  power  transient  recovery  was  rated  as  marginal.  In  particular, 
the  system  status  monitoring  function  displayed  a  wide  range  of  false  failures  after 
power  transients  which  leads  to  some  additional  pilot  comments  concerning  software  system 
design.  (R9)  Even  without  the  added  variables  Introduced  due  to  the  power  transients, 
the  approach  to  system  status  monitoring  left  something  to  be  desired  in  the  pilots 
opinion.  As  stated  earlier,  the  system  uses  an  alert  by  exception  philosophy.  This  of 
course  means  that  you  must  rely  on  the  judgment  and  proper  functioning  of  the  monitoring 
system  to  know  when  something  goes  wrong.  There  are  undesireable  aspects  to  this 
philosophy.  First,  the  pilot  has  no  continuous  way  to  monitor  certain  instruments  to 
establish  trends  so  as  to  anticipate  problems.  (R15)  A  simple  case  in  point  is  the  fuel 
display.  It  takes  a  deliberate  act  of  judgment  on  the  part  of  the  pilot  for  him  to 
display  fuel  status.  This  of  course  means  that  if  this  is  not  done  on  a  regular  basis, 
it  is  possible  for  the  crew  not  to  realize  that  the  external  tanks  did  not  feed  until 
they  get  the  fuel  low  light.  Thus  the  crew  could  find  Itself  deep  into  enemy  territory 
or  far  over  the  water  without  enough  usable  fuel  to  make  it  back.  Furthermore,  if  the 
accuracy  of  certain  displays  is  effected  by  power  transients,  the  crew  would  not  have  any 
baseline  data  upon  which  to  develop  manual  estiutes  since  they  had  not  been  continuously 
monitoring  the  systems. 

The  flight  information  display  is  divided  into  five  basic  categories!  flight 
instrument  values;  engine  and  airframe  instrument  values;  avionics  flight  symbology; 
wacning/csutlons/advlsories  (HCA);  and  general  display  control.  Discussion  of  this  area 
lad  to  very  useful  comments  concerning  display  philosophy  vis-a-v.s  software  implementation. 
Chief  among  these  comments  was  the  need  for  what  one  pilot  called  a  "scratch  pad*.  The 
general  function  of  this  display  is  to  be  a  catch  all  of  inputted  data  to  be  used  for 
monitoring  or  crew  coordination.  Case  in  point  was  the  IFF  squawk  on  the  RH-60.  The 
pilots  coaiplalned  that  it  took  too  many  switch  actions  on  their  part  to  see  irttat  they 
were  currently  squawking.  The  same  was  true  of  the  comm  frequency.  They  felt  that  these 
could  be  display^  on  the  'scratch  pad*.  Also,  this  display  could  be  used  when  a  new 
input  was  being  made  on  a  given  system  to  avoid  confusion,  duplication  of  effort  and  aid 
crew  coordination.  (R16) 

The  second  comment  concerning  displays  was  the  use  of  analog  versus  digital  formats 
in  the  software.  This  would  allow  the  pilot  to  use  trend  Information  such  as  acceleration 
or  decceleration,  which  is  more  easily  accounted  for  with  analog  type  displays.  (R15)  A 
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display  tocmft  featuring  simulated  'round  dials*  for  critical  Instruments  could  make 
trend  Information  available  at  the  pilots'  option, 

Next>  fha  pilots  expressed  their  preference  for  color  displays  ulth  appropriate 
symbology*  hlso,  an  HH-60  feature  they  enjoyed  was  the  ability  to  declutter  the  display 
panel  tor  certain  phases  of  their  mission.  The  last  major  comment  concerning  displays 
was  their  desire  for  the  ability  to  code  select  without  releasing  flight  controls.  (R29) 

Is  susmary,  avionics  software  concerns  revolved  around  Information  management, 
consistent  programming  and  nomenclature,  user  friendly  selection  process,  and  nonlabor 
intensive  power-up  and  data  loading  processes. 

f-16  pilot  comments 

The  E-16  Is  a  single-seat,  single -engine,  multlrole  fighter  made  by  General  Dynamics. 
It  was  designed  as  a  lightweight  fighter  and  optimized  for  the  day,  clear  weather  dogfight 
role.  It  also  has  very  good  all-weather  surface  attack  capability.  The  Falcon  Is  flown 
by  nations  as  diverse  as  Pakistan,  Isreal,  and  the  United  States,  as  well  as  several 
European  countries.  It  was  one  of  the  first  aircraft  to  employ  the  NIL-STD  1553  data  bus 
to  tie  multiple  components  together  Into  an  Integrated  avionics  suite.  The  two  major 
variants  are  the  F-16A/B  and  the  P-16C/D.  From  a  pilot  perspective  the  major  difference 
between  the  two  versions  Is  the  use  of  multifunction  displays  (HFDs)  In  the  C/0  variant 
for  Increased  system  flexibility.  Typical  cockpit  layouts  ace  shown  In  figures  7  and  S. 

Characteristics  of  the  avionics  were  discussed  with  USAF  test  pilots  who  had 
experience  In  both  variants  of  the  aircraft.  Some  comments  mirrored  those  of  F-15  pilots 
covered  earlier,  but  since  the  F-16  started  off  as  a  computer-oriented  machine,  many 
problem  areas  associated  with  pre-takeoff  operations  have  already  been  addressed. 
Therefore  pilots  tend  to  have  more  comments  on  combat  related  capabilities. 

PRE-TAKBOFPt  Pilots  generally  praised  the  display  and  stores  management 
mechanizations.  A  common  rule  throughout  the  system  Is  ’Press  to  change*.  If  what  the 
pilot  sees  Is  not  what  he  wants,  he  simply  presses  the  label.  This  will  rotary  through 
other  available  modes  or  provide  a  menu  of  them.  The  general  feeling  was  that  If  there 
were  three  or  fewer  options,  a  rotary  was  fine.  Por  four  or  more  options,  a  menu  seemed 
easier  to  use.  (R24)  Refer  to  figure  9  for  examples  of  the  process. 

As  with  the  F-15,  stores  loading  drew  several  comments.  For  the  most  part,  the  A/B 
stores  loading  mechanization  was  preferred.  This  is  a  menu-driven  load  procedure  which 
lists  stores  by  abbreviations  of  their  actual  names.  The  pilot  selects  the  stations 
which  he'd  like  to  load,  and  the  stores  management  system  (sns)  shows  the  options 
available.  The  pilot  then  pages  through  the  catalog  and  picks  out  the  desired  store.  In 
the  C/D  mechanization,  no  options  are  presented.  The  pilot  has  to  select  the  desired 
statlon(s),  then  key  In  a  code  for  the  desired  store.  This  code  Is  a  three-digit  number 
having  no  logical  connection  with  the  store  itself,  and  no  list  of  options  Is  presented. 
The  pilot  must  simply  know  the  code.  If  this  type  mechanization  Is  to  be  used,  one  pilot 
suggested  that  a  ‘Help*  page  be  added.  This  would  cross  reference  the  weapons  with  the 
associated  codes.  (R25,R26)  In  addition,  both  mechanizations  drew  criticism  because 
racks  and  pylons  had  to  be  loaded  separately,  even  if  the  store  loaded  could  only  be 
carried  on  a  specific  rack — extra  work  for  no  reason.  (RE) 

One  feature  that  pilots  felt  was  very  useful  was  the  ability  to  tailor  certain 
air-to-air  modes  prior  to  flight.  These  modes  allowed  the  pilot  to  use  a  single  switch 
action  Inflight  to  set  up  radar  search  pattern  as  well  as  weapon  choice.  (R12)  The 
ability  to  set  up  a  master  mode  (air-to-ground  (A-G)  for  example)  exit  that  mode  for 
air-to-air  (A-A)  If  needed,  and  return  to  A-G  without  having  to  reprogram  It  was  also 
considered  valuable.  (R27) 

CRUISE/COMBATi  Every  pilot  expressed  concern  about  the  amount  of  head-down  work 
required  to  use  the  fire  control  and  navigation  panel  (FCNP)  In  the  A/B  model.  This 
particular  panel  must  be  accessed  in  order  to  select  certain  radar  modes,  some  weapons 
delivery  modes,  and  to  update  the  IKS.  Although  this  is  a  hardware-oriented  problem,  one 
possible  solution  would  be  to  put  two  or  three  of  the  most  heavily  used  functions  Into 
hands-on  or  up-front  controls  and  then  display  the  Information  momentarily  on  the  HUD. 
(R29)  The  data  should  be  deselectable,  because  some  pilots  felt  that  the  HOD  was  already 
tecoming  cluttered,  particularly  In  C/D  variants.  (RIO)  Many  numbers  are  presented  In 
the  HUD  and  most  are  unlabeled.  As  a  result,  the  display  has  became  very  difficult  to 
Interpret  at  a  glance. 

Regarding  the  HUD,  pilots  appreclatd  the  use  of  analog  type  displays  for  altitude 
and  airspeed.  (R15)  One  also  praised  the  coanonallty  between  A-A  and  A-G  *in  range* 
displays.  The  HUD  flashes  whenever  entering  weapon  delivery  paraizeters.  The  message  Is 
the  samei  ‘time  to  press  the  button*.  The  wide  angle  raster  (WAR)  HDDs,  In  combination 
with  LAHTIRN  pods,  have  made  night  or  adverse  weather  navigation  easier,  but  they  also 
spread  out  the  altitude  and  airspeed  Information.  One  pilot  noted  that  the  visual  angle 
between  altitude  and  airspeed  In  the  MAR  HUD  Is  actually  larger  than  the  angle  between 
the  two  gages  on  the  Instrument  panel I 

Radar  displays  and  nodes  also  generated  some  comments.  In  general,  pilots  were 
pleased  with  the  radar  presentations  In  both  models  of  the  F-16.  Although  very  different, 
iDoth  are  effective.  Several  felt  that  hands-on  control  of  azimuth  scan  In  a  manner 
similar  to  the  F-15  would  be  deslreable.  Others  wanted  a  heads-up  way  to  change  the  scan 
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patterns.  For  exMplttr  th«  radar  can  aearch  froo  aide~to>side  at  a  constant  elevation, 
or  it  can  change  elevation  sii9htly  fron  s%ieep-*to-sweep  and  search  a  lar9er  volume. 
These  pilots  wanted  to  be  able  to  change  the  pattern  without  having  to  go  head-down  to 
the  radar  panel.  The  radar  was  also  tied  into  the  voice  message  unit  (\ntU),  so  that  in 
certain  radar  automatic  search  and  lock  modes#  the  pilot  would  get  a  "lock”  call  In  his 
headset.  This  would  allow  a  pilot  approaching  an  ares  with  known  hostiles  to  maintain 
simultaneous  visual  and  radar  search.  (R6)  A  final  comment  regarded  the  A/B  radar  display, 
which  presents  a  block  of  information  about  the  target  in  a  section  of  the  display.  In 
some  instances#  the  target  would  drift  into  the  information  block  and  be  occluded.  A 
hands-on  declutter  solved  the  problem  by  removing  the  data  block  on  request. 

Several  comments  regarding  different  systems  emphasised  a  pilot  desire  for  consistent 
switchology  and  displays.  One  button  on  the  side-stick  has  multiple  uses.  As  the  nose- 
gear  steering  switch,  it  toggles  the  steering  on  and  off.  As  the  missile  step  button,  it 
rotaries  through  all  loaded  missilea  of  a  given  type.  But  during  certain  A-G  deliveries, 
it  becomes  a  one-way  switch  to  go  from  the  currently  selected  mode  to  a  continuously 
computed  Impact  point  (CCIP)  delivery  mode.  Pressing  the  switch  again  has  no  effect.  A 
switch  which  has  always  been  a  rotary  has  suddenly  gone  bad#  and  the  pilot  must  go  back 
to  the  SN8  to  regain  the  previous  delivery  mode.  (R7) 

On  the  positive  side,  pilots  were  generally  pleased  with  the  target  management 
switch  (ThS)  on  the  stick.  No  matter  what  mode  the  pilot  had  selected,  the  TNS  always 
seemed  to  do  what  was  expected t  it  always  caused  a  sensor  or  system  to  become  stabilized 
wherever  It  happened  to  be  looking  or  located  at  the  time.  No  thinking  was  required, 
because  the  purpose  was  so  consistent  from  mode  to  mode.  (R23) 

RBCOVBRYt  One  software  feature  given  high  marks  by  pilots  was  a  set  of  "cruise* 
modes.  These  are  essentially  fuel  management  modes  which  give  the  pilot  speed  and/or 
altitude  cues  for  best  using  his  remaining  fuel.  "Endurance",  "Range",  and  "Home*  modes 
would  not  only  provide  the  proper  speed  and  altitudes  to  fly  as  a  function  of  gross 
weight#  but  they  would  also  take  into  account  the  drag  of  all  loaded  stores  in  making  the 
computations,  the  "Rome"  mode  would  also  give  the  pilot  a  predicted  fuel  remaining  when 
overhead  the  field.  Software  like  this  makes  superb  use  of  the  things  a  computer  does 
best.  It  provides  "information*  to  the  pilot  rather  than  unprocessed  "data*.  (R6) 


RECONHENOATIONS 

The  specific  recommendations  below  arise  as  a  direct  result  of  user  interviews 
discussed  earlier.  Each  is  directly  related  to  one  or  more  specific  suggestions.  They 
are  not  listed  in  any  particular  order,  but  the  authors  recommend  special  consideration 
be  given#  as  a  minimum,  to  four  underlying  concepts: 


A. 

B« 

Keep  switch  actions  to  a  minimum,  particularly  in  the  heat 
error  recovery. 

Keep  switchology  consistent  throughout  the  mechanization. 

of 

battle 

or 

for 

C. 

Keep  "display  options”  visible#  but  tailor  default  displays 
planned  phase  of  flight. 

specially 

for 

the 

D. 

HOST  INPORTANT,  provide  the  pilot  with  useable  "information”, 
unprocessed  "data"  only  Increase  pilot  workload.  PRE-PROCESS  IT! 

Megabytes 

of 

Specific  Recommendations 

1.  Always  include  a  single  action  "return  to  start”  capability  in  any  menu-driven 
software.  (This  is  In  addition  to  the  standard  "back-up  on  page*  capability.)  Single 
action  recovery  from  erroneous  keystrokes  is  also  a  must. 

2.  Automate  data  entry  whenever  feasible.  (This  is  obviously  a  hardware  intensive 
recommendation. ) 

3.  Don't  display  "non-options”.  If  certain  software  paths  are  deadends,  don't  allow 
the  pilot  to  enter  them. 

4.  Avoid  using  similar  words  that  could  generate  confusion. 

5.  To  reduce  workload,  get  the  proper  systems  talking  to  each. other,  rather  than  to  the 
pilot.  INS  should  talk  to  flight  controls,  RHR  should  talk  to  BCN,  etc. 

6.  Use  pictures  Instead  of  words  whenever  possible.  If  color  is  available,  use  it  to 
maximum  advantage. 

7.  Be  consistent,  not  only  in  mode  selection  switchology,  but  in  displays  as  well. 

8.  Use  the  computational  capabilities  to  improve  a  mechanization  rather  than  "putting 
the  old  mechanization  on  the  computer". 

9.  Systems  should  eventually  reach  the  modes  commanded  by  the  current  switch  placement. 
If  intermediate  modes  are  required#  the  system  should  cycle  through  them  automatically, 
even  if  the  recycle  is  due  to  a  power  transient. 


10.  ‘HlsslooO**  displays  to  aaphasize  the  correct  information  and  reduce  clutter, 
but  make  additional  information  available  if  specifically  requested. 

11.  The  9Stem  shouldn't  keep  secrets.  The  pilots  should  be  able  to  read  (but  not 
neceaaarilr  change)  any  mission  or  failure  state  information  in  the  computer  if  he  has 
the  time  to  access  it. 

12s  fr«‘*prograwiing  ooAbat  aodas  prior  to  flight  can  save  j^ecious  seconds  later. 

X3,  Be  disciplined  about  adding  *bells  and  whistles*.  Don't  just  present  bore  data 
oecsuse  it's  available.  Process  the  *data*  and  present  "inforaation* .  Be  sure  the 
addition  will  be  useable  in  the  heat  of  battle. 


14.  &aart  initialisation  is  a  must  for  any  quick  reaction  systes.  They  should  be  set  up 
for  the  ”bost  probable*  quick  response  scenario*  not  the  *worst  case”. 

15.  Long**tem  trend  inforaation  on  systeas  like  engine  and  fuel  should  be  easy  to  access. 
Short-tera  trend  inforaation  for  things  like  altitude  or  airspeed  aust  be  constantly 
displayed*  preferable  in  analog  foraat.  Por  these  applications*  standard  aechanical 
displays  aay  be  better  than  digital. 


16.  Por  aultiplace  aircraft*  a  scratch  pad  type  display  alght  iaprove  inforaation  flow 
throughout  the  aircraft. 

17.  Often  changed  items  like  radio  frequency*  altimeter  and  squawk  shouldn't  be  hidden 
behind  menu  pages.  They  should  be  readily  available  at  all  times. 

18.  There  must  be  increased  pilot  participation  early  in  the  software  design  phase  to 
make  certain  that  what  users*  have  requested  is  understood  by  the  actual  programmers. 


19.  Simulations,  even  simple  PC-based  ones*  should  be  used  whenever  possible  to  show 
pilots  how  planned  mechanisations  will  work. 

20.  When  simulations  are  used*  every  effort  should  be  made  to  use  the  actual  hardware 
and  software  that  will  be  used  in  flight. 

21.  Quantitative  measures  of  performance  should  be  used  during  pilot  evaluations  if 
possible.  This  will  produce  more  objective  results. 

22.  Aural  cues  are  a  good  option  for  warning  information.  When  they  are  used*  words  are 
better  than  more  horns  or  tones.  Por  normal  trends  (like  airspeed)  artificial  wind  noise 
might  be  appropriate. 

23.  A  specific  switch  should  do  functionally  equivalent  things  no  matter  what  master 
mode  the  system  is  in. 

24.  Be  flexible  regarding  rotary  versus  menu  formats  for  switches.  When  options  are  few* 
use  a  rotary.  When  options  are  many*  use  a  menu. 

25.  Henu-driven  software  is  generally  preferable  to  code  word  driven,  both  for  mental 
workload  as  well  as  reduced  switch  actions. 

26.  Make  "Help*  pages  available  for  complex  or  code  word  oriented  sections  of  the 
mechanisation. 

27.  Weapons  modes  should  not  reinitialise  when  exited  and  re-entered.  They  should 
remain  as  the  pilot  last  saw  them. 

28.  Whenever  possible,  avoid  the  use  of  simultaneous  switch  actions  (such  as  designate 
and  hold  while  slewing). 

29.  Use  the  hands  on  throttle  and  stick  (HOTAS)  philosophy  for  heat  of  battle  switch 
actions. 
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DISCUSSION 


W.UrMhel,  US 

Current  design  efforts  have  used  one  of  two  extremes  —  either  the  pilots  are  ignored  by  the  designs  until  flight  test  or 
the  pilots  are  brought  in  early  via  cockpit  working  groups  and  end  up  judging  or  proposing  specific  design  solutions,  not 
just  functional  requirements.  What  is  the  solution  to  this? 

Author’s  Reply 

Pilot  evaluation  of  proposed  changes  through  simulation  facilities  allows  decisions  on  adoption  of  changes  to  be  based 
on  empirical  test  results,  not  just  biased  opinions.  Thus,  each  proposed  mechanization  or  change  should  be  evaluated  by 
multiple  pilots  on  the  simulator  and  decisions  on  implementation  should  be  ba.sed  on  simulation  evaluation  results,  not 
just  individual  pilot's  desires. 

To  summarize: 

a.  Get  pilot  inputs  early. 

b.  Vali^te  plans  via  realistic  operational  tasks. 

c.  Keep  pilots  involved  as  system  takes  shape. 


J.G.Brcvot,  Fr 

1.  What  is  the  schedule  for  the  completion  of  the  "Pilot's  Associate"  (PA)  program? 

2.  What  are  the  first  sophisticated  applications  that  you  envision  in  this  program? 

Author’s  Reply 

1 .  Sinra  the  development  of  the  PA  concept  will  be  evolutionary,  incorporating  improvements  and  modifications 
gradually,  no  actual  “completion"  is  likely  possibly  ever.  Like  an  air-to-air  missile  program,  new  and  better 
versions  will  continue  to  be  tested  and  built 

2.  This  is  probably  the  more  impottam  question,  also  more  difficult.  I  would  expect  some  forms  of  safety-oriented 
ftinctions,  like  automatic  terrain  avoidaiice,  automatic  aitcraf)  out-of-control  recovery  or  automatic  air-to-ground 
weapons  delivery  to  be  the  most  reasonable  systems  to  be  operational  first.  There  may  also  be  better  target 
recognition  systems  within  the  next  few  years. 


L£  RESnMSUU  OE  L'EXPRESSlOli  BU  KSOIN  FACE  AUX  INCERTITUDES 
LIEES  AUX  TECHHiqUES  K  L' IRTELLIGEMCE  ARTIFICIEUE 
ET  OES  STSTEKS  EXKRTS  SUR  LES  AVIONS  DE  COMBAT 
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Colonel  Jean-Georges  BREVOT 
Chef  de  la  Division  Nouveaux  avlons  de  combat 
Bureau  des  pro^ranines  de  matdrlels 
Etat-najor  de  rarmde  de  1'alr  fran(a1se 
24,  boulevard  Victor  -  75996  PARIS  ARMEES 
FRANCE 


SOWAIRE 


Cette  coanunlcatlon  analyse  d'une  part  le  travail  que  do1t  mener  1e  responsable  de  1 'expres¬ 
sion  du  besoln  pour  rddiwr  les  spdcificatlons  d'un  avion  de  combat,  et  d'autre  part  les  questions  qu'11 
se  pose  sur  les  posslbllltds  rdelles  offertes  par  les  techniques  de  1 ' Intel 1 Igence  artlflclelle  et  des 
systtaies  experts. 

t'auteur  en  dddult  que  la  specification  de  1'emplol  de  ces  techniques  sur  avion  de  combat 
constitue  une  sdrieuse  dlfflcultd  et  propose  des  solutions  pour  surmonter  cette  difficultd. 


abreviatichs 


lA  -  Intelligence  artlflclelle 
SE  -  Systtme  expert 


L'apparltlon  des  techniques  de  I'lntelllgence  artlflclelle  dans  les  domalnes  de  I'adronau- 
tlque  mllltalrc  est  un  fait  marquant  de  ces  dcmlires  snn<es. 

Le  responsable  de  I'expresslon  du  besoln,  dont  le  travail  consiste  X  prdvolr  les  conditions 
d'exdcutlon  future  des  missions,  se  dolt  d'en  tenlr  compte.  II  se  heurte  cependant  X  un  certain  nombre 
d' Incertitudes  llfes  X  ces  nouvelles  techniques.  Incertitudes  venant  s'ajouter  X  celles  qui  accompagnent 
normaiement  le  travail  de  redaction  des  specifications  opdratlonnelles. 

Nous  allons  analyser  les  Incertitudes  de  I'expresslon  du  besoln,  celles  lldes  X  I'lntelllgence 
artlflclelle  et  tenter  de  ddgager  quelques  solutions  pour  exploUer  au  mieux  les  possibllltes  nouvelles. 


1  -  I'EXWESSIOM  W  BESOIN 


I.l  -  Les  specifications  oodratlonnelles 

Le  travail  du  responsable  de  I'expresslon  du  besoln  en  Etat-major  se  heurte  X  de  nombreuses 
difficultes,  en  particuller  lorsqu'11  a  trait  au  domalne  des  avlons  de  combat. 

II  consiste  en  effet  X  savoir  se  proTeter  dans  I'avenlr,  et  le  chemlnement  de  la  pensde  per- 
mettant  da  ddgager  les  caractdrlstlqucs  essentielles  du  besoln  dolt  en  fait  tenlr  compte  de  nombreuses 
Incertitudes. 


Une  Incertitude  Importante  tient  au  fait  que  I'adversalre  ne  nous  donne  pas  ses  Intentions  et 
11  convlent  de  tenter  de  les  prdvolr.  Une  autre  Incertitude  est  due  aux  peredes  technologlques  souvent  Imprd- 
vlstbles. 


Toutas  les  reflexions  dolvent  prendre  place  dans  un  cadre  reprdsente  par  la  meMce.  Or  cette 
menace  ddpend  bicn  entendu  de  la  technologle  dont  dispose  I'adversalre,  mals  dgalament  de  revolution  des 
situations  gdopolltlques  et  des  rapports  de  force.  Chacun  salt  que  cette  Evolution  est  partIcullXrement  dif¬ 
ficile  X  prdvolr. 

Tout  ce  travail  sc  tradult  par  la  redaction  des  specifications  opdratlonnelles  qui  constituent 
un  docuaent  de  base  auquel  se  rdfXre  constamment  rutilisateur  au  cours  du  ddroulement  d'un  programne. 

$1  ce  document  est  bicn  rddlgE  : 

-  on  peut  escomptar  que  le  material  rempllra  le  besoln,  c'e$t-X-d1ra  qu'11  se  montrera  efficace 
pour  rmapMr  la  mission, 

-  mals  on  peut  dgalement  escompter  que  le  material  rempllra  Juste  le  besoln  ;  ce  qui  signifle 
que  ton  coOt  sera  ralsonnablc  e'est-X-dIre  rentrant  dans  le  voliane  financier  qui  peut  Etre 
consacrE  au  prograamm. 


f  — 


1.2  -  La  prjvlston  de  la  mission 

II  s'agit  done  de  prdvoir  la  nature  et  les  conditions  d'exfcution  de  la  mission  dans  un  futur 
i  long  terme  et  d'en  ddduire  1e  besoln  correspondent. 

Mals  de  quel  long  terme  s'ag1t-11  7  £n  noyenne  1e  ddvel oppenent  d'un  avion  de  combat  prend 
10  ans,  et  ensulte  1 'avion  va  avoir  une  durde  de  vie  dans  I 'Annie  de  1'alr  utlllsatrice  de  1'ordre  de  25 
ans,  avec  trbs  souvent  une  rdnovation  i  mi-vie.  II  faut  done  privoir  I'ivolutlon  des  stratigles  et  des  tac- 
tlques  sur  une  pirlode  de  35  ans.  ce  qui  n'est  pas  une  Uche  aisie. 

Void  i  titre  d'exemple  quelques  unes  des  grandes  questions  qui  se  posent  dans  la  privislon 
de  ce  futur  b  long  terme. 

-  Les  missions  offensives  seront-elles  exicuUes  par  avions  Isolds,  par  patroullle  ou  par 
raids  massifs  7 

-  Compte  tenu  des  menaces  et  des  parades  possibles,  les  altitudes  optimales  seront-elles 
basses  ou  hautes  7 

Queues  seront  les  vltesses  assoclies  7 

-  Faudra-t-11  privlligier  la  vitesse  ou  la  manoeuvrablllti  ? 

-  Les  missions  de  supiriorlti  airlenne  s'effectueront-el les  sous  guldage  complet  ou  au  contraire 
de  fagon  la  plus  autonome  possible  7 

-  Quelle  sera  la  quallti  de  I'ldentlflcatlon  et  de  la  coordination  sur  le  champ  de  batallle  7 

Hals  queues  que  solent  les  solutions  envisagies,  11  reste  que  les  matirlels  devront  toujours 
(tre  congus  pour  penaettre  d'explolter  au  mieux  les  oualltes  imnuables  de  1 'aviation  de  combat  :  la  souplesse 
d'emploi,  I'aptltude  i  la  concentration,  la  rapiditi  d'acticn  dans  la  profondeur. 

1.3  -  L'ivolutlon  technologloue 

Une  des  tiches  essentlelles  du  responsable  de  1 'expression  du  besoln  consiste  b  sulvre  avec  at¬ 
tention  I'ivolutlon  des  technologies  et  b  en  privoir  les  tendances.  Malheureusement  son  travail  est  compllqui 
par  le  fait  que  cette  ivolutlon  n'est  Jamals  une  progression  constante.  L'imergence  de  nouvelles  technolo¬ 
gies  peut  crier  des  percies  dlfflcllement  privisibles  contre  lesquelles  11  convient  de  se  primunir,  ou  au 
contraire  qu'11  faut  tenter  d'explolter. 

Cependant  on  peut  constater  en  cette  metibre  une  caractirlstique  qui  s'est  toujours  virlflie 
dans  I'hlstolre  des  techniques  mllltalres  ;  raltemance  entre  I'avantage  de  1  'jpie  et  celul  de  la  culrasse. 
Actuellement  on  peut  constater  un  avantage  asset  net  en  faveur  de  1'ipie,  c'est-VdIre  de  1 'action  offensive, 
due  b  la  sophistication  des  systbmes  d'armes,  des  armements  et  des  missiles.  Hals  les  tendances  technolo- 
glques  actuelles,  en  particuller  dans  les  domalnes  des  contre-mesures.  de  la  furtivlti  ou  du  durcissement 
des  objectifs,  font  penser  qu'on  pourralt  asslster  b  un  retour  de  I'avantage  en  faveur  de  la  culrasse  e'est- 
b-d1re  de  la  position  difensive. 

Void  b  titre  d'exemple  quelques  domalnes  technologiques  ayant  eu  ou  devant  avoir  un  Impact 
certain  sur  les  conditions  d'exicutlon  des  missions,  done  sur  la  difinitlon  du  besoln  en  matibre  d'avlons 
de  combat  : 

-  les  progrbs  dans  I'efflcaclti  des  missiles. 

-  1'arrlvie  des  commandes  de  vol  ilectriques, 

-  la  mise  au  point  des  techniques  pulse-doppler  sur  les  radars  de  bord, 

-  1 'optronique, 

-  1'au^ntatlon  de  la  precision  de  navigation, 

-  les  possibllltis  de  coordination  du  champ  de  batallle, 

-  1 'au^nentatlon  explosive  de  la  puissance  des  calculateurs  de  bord, 

-  et  blen  entendu  I'arrlvie  des  techniques  de  1 'Intelligence  artificlelle  et  des  systbmes 
experts. 

1.4  -  Les  dllemnes 


1.4.1  -  Le  dllemne  efficaciti  /  coOts  -  dilals 

La  premlbre  quallti  d'un  matirlel  mllltaire  est  d'btre  efficace.  Mats  cette  efficaciti  n'est 
pas  forciment  obtenue  par  I'acciaeulatlon  de  fonctlons.  Elle  est  plutbt  le  risultat  de  la  criatlon  d'un 
ensemble  cohirent. 

Cependant  la  riallsatlon  de  cet  ensemble  cohirent  se  heurte  aux  limitations  dues  aux  coDts 

et  aux  dilals. 
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-  La  llailtatlon  essentlelle  due  aux  cofits  est  celle  qui  ressort  du  ddfaat  aualltd  /  auantltd 
dans  un  volume  budgdtaire  donnd.  L'inpact  du  facteur  quantity  ne  dolt  pas  fitre  sous- 
estlmd  car  11  apporte  d'une  part  1'effet  de  nombre  en  matlbre  d'efficacltd  opdration- 
nelle  et  d'autre  part  I'effet  de  sdrie  entratnant  une  rdductlon  des  prix  unitalres. 

-  La  limitation  due  aux  ddlals  vient  ensulte  et  oblige  h  savoir  arrtter  la  definition  du 
materiel  sur  une  technologle  donnee  et  b  dvlter  1e  perfectlonnisme. 

1.4.2  -  Le  dlleaine  demande  excessive  /  exploitation  des  possibllltes 

La  limitation  essentlelle  que  rencontre  done  le  responsable  de  1 'expression  du  besoln  est 
celle  des  cofits.  Un  programne  est  toujours  realise  b  1'lnterleur  d'une  enveloppe  financibre  donnde  et  11 
convient  d'aboutir  b  une  definition  du  materiel  rempllssant  au  mieux  le  besoln  sans  depasser  cette  enve¬ 
loppe. 


£n  revanche  la  limitation  des  cofits  peut  fitre  un  moteur  favorlsant  le  progrfis  des  applica¬ 
tions  technologlques.  Elle  oblige  les  Ingfinleurs  b  se  remettre  en  cause  et  b  constaimnent  rechercher  de 
nouvelles  techniques  plus  adaptees  pour  assurer  une  fonctlon  requise. 

Tous  ces  elements  placent  le  responsable  devant  un  dllemne  difficile  :  celul  de  ne  pas  ex¬ 
primer  le  besoln  sous  une  forme  qui  condulralt  b  une  realisation  excedent  I'enveloppe  financifire,  s'oppp- 
sant  b  la  crainte  de  manquer  1 'exploitation  optimale  des  possibllltes  technologlques  offertes. 

Une  autre  dlfflcultfi  reside  dans  le  fait  qu'11  n'existe  pas  reellement  dans  les  Etat-majors 
de  personnels  capables  de  combler  le  fosse  qui  existe  entre  I'operatlonnel  et  I'lngenleur.  II  faudralt  en 
quelque  sorte  des  opdratlonnels  capables  de  se  plonger  dans  la  technique  pour  en  eilmlner  tout  ce  qui  est 
superflu  ou  Inutllement  cofiteux  et  au  contraire  dficeler  toute  application  potentlellement  efficace  pour 
rdallser  la  mission. 

1.5  -  La  charge  de  travail  d'un  equipage  d'avlon  de  combat 

L'etude  des  conditions  d'exficutlon  des  missions  de  1 'aviation  de  combat  moderne  montre  que 
ces  missions  vont  en  se  compllquant  dans  un  envi ronnement  opdratlonnel  de  plus  en  plus  hostile  et  difficile 
b  mattrlser. 


De  ce  fait  la  charge  de  travail  d'un  equipage  d'avlon  de  combat  va  en  augmentant  de  facon 
quasi  explosive.  Get  equipage  dolt  tout  b  la  fols  : 

-  assurer  le  pilotage  de  1 'avion, 

-  assurer  le  posltlonnement  de  1 'avion  et  en  particuller  la  navigation, 

-  mattrlser  le  mieux  possible  la  situation,  ce  qui  signifie  :  percevolr.  Identifier  et  sjmthe- 
tiser, 

-  decider  de  la  tactique  b  court  terme  (la  manoeuvre)  et  b  long  terme  (la  condulte  de  la 
mission), 

-  assurer  I'auto-defense  la  plus  efficace, 

-  gfirer  les  moyens  offenslfs, 

-  gfirer  les  senseurs  en  cherchant  b  la  fols  la  mellleurc  efflcacltfi  et  la  discretion, 

-  gfirer  les  pannes  et  fiventuellement  les  consfiquences  des  coups  regus  de  I'adversalre. 

Tout  cela  Impllque  un  excellent  dialogue  entre  I'fiqulpage  et  le  systfime.  II  faut  done  fitudler 
avec  une  particullfire  attention  1' Interface  homme  -  machine  :  qualitfi  des  visualisations,  viseur  -  visual 
de  casque,  qualitfi  des  logiques  systfime,  commandes  temps  rfiel,  comnandes  sensitives.  Informations  et  com¬ 
mandos  vocales. 

Par  allleurs  la  limitation  des  cofits  de  possession  (e'est-b-dira  b  la  fols  des  cofits  d'ac- 
qulsltlon  et  des  cofits  de  fonctlonnement)  conduit  b  rechercher  des  avions  de  tallle  llmltfie  servis  par  des 
personnels  les  molns  nombreux  possible.  La  tendance  est  done  d'aller  vers  des  avions  monoplaces  o!i  par 
consequent  le  pllote  dolt  exficuter  seui  1 'ensemble  des  tlches  prfisentfies  plus  haut. 

Pour  que  la  charge  de  travail  du  pllote  ne  devlenne  pas  rapidement  Impossible  b  gfirer,  11 
convient  de  faire  assurer  par  le  systfime  une  aide  filaborfie,  d'ob  1 'apparition  du  concept  de  "copllote 
filectronlque"  et  I'lntfirfit  particuller  portfi  aux  techniques  de  1 ' Intel  1 1gence  artificlelle  et  des  sys- 
tfimes  experts. 
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2  -  L£S  TttWIIOUES  DC  flWElLie^fg  MTIFlCIttU  (U)  CT  DES  STSTOCS  EgEMS  (SEl 

2.1  -  D«  guol  s'aQlt-n  ? 

La  premitre  difricuitt  <)ue  rencontre  I'opdratlonnel  en  pdndral  et  1e  responsable  de  I'ex- 
presslon  du  besoln  en  Etat-major  en  particuller,  eit  dc  blen  comprendre  de  quol  11  s'ajit  quand  sont 
abordds  les  probltmes  lids  aux  techniques  d'lA. 

11  faut  en  effet  constater  que  les  spdclallstes  de  I'lA  n'ont  pas  toujours  un  lanqage  claIr 
pour  faire  comprendre  les  avantages  de  leurs  techniques.  Le  terme  m(me  d'*1nte111^ce  artlflclelle",  gal- 
vaudd  par  les  joumallstes.  maintlent  A  tord  sur  ces  techniques  un  caracttre  dsotdrique  et  11  vaudralt 
mieux  le  remplacer  par  “Infotmatloue  coonltlve*  (c'est-A-dIre  qui  a  trait  A  la  connalssance). 

Le  Ubieau  1  donne.  par  comparalson  entre  les  techniques  Informatlques  classiques  et  les 
techniques  d'lA,  les  Informations  qu‘11  nous  paralt  ndcessaire  d'expllquer  aux  responsables  pour  leur  faire 
sal  sir  tout  I'lntdrdt  de  I'approche  lA. 

2.2  -  Les  domalnes  d'apollcatlon 

Les  techniques  d'lA  ont  pemis  d'aborder  des  problAmes  qu‘11  dtalt  Jusqu'A  prdsent  Impossible 
de  tralter  par  I'lnformatlque  du  fait  de  leur  complexltd.  Les  domalnes  d'appllcatlon  reprdsentent  done  un 
potentlel  pratiquement  Infinl,  et  11  s'agit  de  sdlectlonner  ceux  qui  prdsentent  un  IntdrCt  pour  les  actlvl- 
tds  mllltalres. 

2.2.1  -  Domalnes  en  relation  avec  renvlronnement 

Ce  sont  des  domalnes  cherchant  A  reproduire  des  activltds  de  base  de  1 'Intelligence  humalne 
en  rapport  avec  la  perception.  La  rdussite  dans  ces  domalnes  est  llde  essentlellement  A  la  puissance  de  cal- 
cul  dont  on  peut  disposer. 

On  y  trouve  essentlellement  les  deux  domalnes  sulvants  : 

-  la  reconnaissance  de  la  parole,  qui  permettralt  un  dialogue  vocal  direct  entre  le  pllote 
et  le  systAme, 

-  le  traltenent  et  1' Interpretation  d'lmages,  la  reconnaissance  des  formes  et  I'analyse  des 
scAnes. 


TABLEAU  1 
TECHNigUES  INFOmTiqUES 


APPROCHE  CLASSigUE 


-  Progranmatlon  procAdurale  algorlthmique  e'est- 
A-dlre  oti  toute  la  connalssance  est  employee 
dans  le  mAme  ordre  en  sulvant  pas-A-pas  un  en- 
chaTnement  d'lnstructlons  appeie  algorlthme. 

-  Instructions 


-  Algorlthme  assurant  un  ordre  d' execution  des 
Instructions 

-  Traltement  de  donnees 

-  Proedde  determlniste,  e'est-A-dIre  utlllsant 
toujours  les  mAmes  dMuctlons 


APPROCHE  lA 


-  Progranmatlon  declarative  qui  consiste  A  declarer 
toute  ses  connal stances  sous  forme  de  rAgles  puls 
A  ne  les  employer  que  quand  elles  sont  ndcessalres 
grAce  A  un  ralsonnement  approprie. 

-  RAgles,  e'est-A-dIre  un  formallsme  tradulsant  les 
connalssances 

-  Moteur  d'lnfArence,  e’est-A-dIre  un  InterprAtateur 
de  connalssances  assurant  le  ralsonnement 

-  Traltement  de  falts 

-  ProcAde  heurlstique,  e'est-A-dIre  cherchant  A  trouver 
la  solution  avec  un  ralsonnement  adapte  aux  falts  A 
tralter 


Cherche  la  mellleure  solution  thdorlque 


Temps  de  traltement  des  problAmes  complexes 
pouvant  devenlr  explosif 


-  Cherche  la  solution  optlmale  en  function  des  falts 
et  du  temps  Imparti 

-  Temps  de  traltement  des  problAmes  complexes  pouvant 
Atre  adapte  aux  dAlals  Imparti s 


SystAme  classique 


Base  de 
donnAes 


SystAme  expert 
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2.2.2  -  DomIms  d«i  syttits  «xD«rts  (SE) 

Ce  sent  les  doMlnes  prdsenUnt  U  potcntlillU  la  plus  pranda.  Ils  font  plelnaaient  appal 
t  I'approcha  lA  das  tachniquas  Infonaatlquas  an  utlllsant  las  systinas  axparts.  La  connalssanca  utlllsda 
dolt  done  Itre  racualllla  aupris  das  axparts  iillltalras. 

Signalons  d'abord  brlivasMnt  las  dooMlnas  an  rapport  avac  la  concaptlon  at  la  fabrication  das 
natdrlals  adronautlquas  car  11s  Intdrassant  surtout  las  Industrials.  Capandant  cas  donalnas  dolvant  (tra 
sulvis  par  las  utlllsataurs  car  11s  ont  das  rdparcusslons  sur  das  activltds  dans  lasquallas  cas  damlers 
sont  partia  pranante  : 

-  I'archltactura  das  systiaias. 

-  las  dtudas  da  sdcurltd, 

-  I'alda  b  la  specification  technique. 

Les  donalnas  qui  an  revanche  Intdressent  plalnanant  las  utlllsataurs  sont  las  sulvants  : 

-  I'alda  b  la  malntananca,  la  diagnostic  da  pannes. 

-  I'alda  b  r Interpretation  das  signaux  radar  at  radio. 

-  I'alda  b  ridantificatlon. 

-  la  simulation,  avac  comne  applications  principales  ; 

-  la  simulation  da  I'actlvlte  da  grandas  unites  mllltalres  (divisions,  unites  adrlennes. 
f lattes  marl  times), 

-  la  simulation  da  scenarios  at  da  modes  d'actlon  strateglquas. 

-  I'alda  b  la  prise  da  decisions,  domalna  extremament  vaste  dont  les  applications  principales 
soni  ; 

-  I'alde  au  connandement  compranant  les  actlvltds  sulvantes  :  1 'analyse  stratdglque  et 
tactique,  I'etabllssament  de  plans  d'attaque  et  de  defense,  I'analyse  et  I'lnterpreta- 
tlon  du  renseignement,  I'affactatlon  das  rassourcas, 

-  I'alda  b  la  condulte  das  systbnes  dont  las  applications  principales  pour  las  avions  de 
combat  sont  la  preparation  das  missions  at  surtout  toutes  les  actlvltds  embarqueas 
couvertas  par  la  vocable  "copllote  eiactronlque". 

2.2.3  -  La  copllote  eiactronlque 

La  but  general  das  applications  d'lA  embarquee  est  tout  d'abord  d'aliegar  la  charge  de  travail 
du  pllote  pour  1u1  dvlter  un  problime  da  saturation  et  ensulte  de  1 'alder  dans  la  realisation  de  tlchas  com¬ 
plexes  an  particuller  dans  les  prises  da  decisions.  On  devralt  alnsi  1u1  permettre  de  mieux  se  concentrer 
sur  I'essentlal  at  done  d'etre  plus  afficace. 

De  nombrauses  activltes,  ditas  de  "copllote  eiectronlque”,  peuvent  faire  I'objet  d'appllca- 
tlons  lA  plus  ou  mol  ns  complexes  : 

-  la  gestlon  da  la  mission  at  da  la  tactique  b  long  terme. 

-  I 'optimisation  de  la  penetration, 

-  i'alda  aux  manoeuvres  d'angagemant  air-air, 

-  revaluation  da  1' anvl ronnemant  et  la  mattrlse  de  la  situation, 

-  la  gestlon  das  captaurs, 

-  la  surveillance  das  systbmas  et  laur  reconfiguration, 

-  ridantificatlon  et  la  classification  das  menaces, 

-  la  gestlon  das  moyans  da  broulllage  at  de  leurrage, 

-  la  determination  da  I'orlglna  das  pannes,  de  leurs  consequences,  das  actions  curatives  et 
las  propositions  da  procedures  d'urganca. 

Toutes  cas  applications  ont  un  point  commun  :  alias  dolvant  Stre  reallsdas  sous  forme  da  so¬ 
lutions  proposeas  au  pllote  b  1' exclusion  da  tout  automatlsma  systematiqua,  una  proposition  de  solution 
erronde  resunt  malheureusament  toujours  possible  coeiaa  on  le  verra  plus  loin.  La  pllote  dolt  raster  1e 
saul  Juga  da  I'opportunlte  da  la  decision  at  las  automatlsmas  na  pauvant  Itre  envisages  qua  sur  autorlsa- 
tlon  da  calul-cl. 
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Une  difficult^  laporUnte  rdside  dans  It  aamiiia  d'aptituda  actual  das  systtaas  axparts  I 
opdrar  an  taaiDs  rdal.  Las  ddcistons  dolvant  an  affat  (tra  prisas  trks  rapidaaant  dans  un  avion  da  ccaibat. 
11  y  a  done  das  progrts  k  rdallsar  an  aatltra  da  rapldltd  das  caleulataurs  da  bord  at  da  laur  adaptation 
aux  proeddds  da  traltaaant  lA.  Quolqu'll  an  solt.  11  faudra  toujours  trouvar  un  coapronls  antra  la  ddlal 
accordd  k  rdtabllssaaant  d'una  solution  at  la  qualltd  da  catta  solution. 


2.3  -  Las  avantaoas  apDortds  par  las  systbaas  axparts  (SE) 

11  Inporta  qua  la  responsabla  da  1'axprasslon  du  basoln  an  Etat-najor  solt  blan  au  fait  das 
avantagas  apportds  par  las  SE  pour  savolr  quals  sont  las  basolns  qui  pauvent  Itre  pris  an  conpta  par  las 
techniques  correspondantes . 

-  Las  SE  sont  capablas  da  tralter  des  problines  qu'11  dtalt  Inpossibla  de  tralter  auparavant 
du  fait  de  laur  coaolexltd.  Gael  rdpond  blan  aux  probibnes  de  I'avlatlon  da  conbat  nodame  ; 
dvolutlvltd  crolssante  des  situations,  nultipllcatlon  des  Infonnatlons,  envl ronnanant  hau- 
tanent  conplaxa  at  non  structurd. 

-  Las  SE  sont  capablas  da  traitor  des  falts  Incartalns. 

-  Las  techniques  des  SE  apportant  b  I'axpartlsa  ;  I'accianulatlon.  la  pdrennitd,  I'ublqultd 
at  la  disponibllltd. 

-  Las  SE  pemattent  d'assurar  das  dialogues  honne  -  nachina  ‘Intalllgants*. 

-  Las  SE  sont  capablas  si  ndcassaire  d'axpllquar  la  raison  des  solutions  qu'lls  proposent. 

-  Las  parfomancas  das  SE  ne  sont  affeetdes  n1  par  la  stress  du  conbat,  n1  par  la  panique. 

-  Enfin  las  SE  sont  faclles  b  andllorer  at  b  modifier. 


2.4  -  Las  difficultds  lldas  aux  svstbnes  experts  (SE) 

11  faut  an  revanche  dtra  consclent  d'un  certain  nonbra  de  difficultds  erddes  par  las  SE. 

Tout  d'abord  un  SE  n'a  de  valour  qua  par  la  qualltd  da  rexpertlsa  qu'11  contlent.  Catta  ax- 
partlsa,  foredmant  linltda  par  la  nonbra  da  rdglas  qu'11  est  possible  da  nattra  an  oeuvre,  peut  dtra  1n- 
ccnplbta  ou  Inparfalte.  Las  rdglas  d'expertlse  peuvant  (tra  contestdas  salon  las  experts  quand  on  aborde 
das  sujets  pour  lesquals  las  solutions  dldmentalres  no  sont  pas  dvidentas,  ca  qui  ast  souvent  la  cas  an 
enplol  opdratlonnal.  Enfin  las  parfomancas  des  SE  so  ddgradant  tris  rapidemant  quand  on  so  trouve  dans  des 
conditions  d'utlllsatlon  qui  s'approchent  des  Unites  da  rexpertlsa  utlllsde. 

Pour  toutes  ces  raisons  un  SE  peut  parfols  donnar  une  solution  erronde  ou  tout  au  mol  ns  Inop¬ 
portune.  Cela  ast-11  acceptable  sur  un  avion  de  conbat  ?  Oul,  b  condition  qua  las  solutions  proposdes  par 
las  SE  ne  ddbouchent  pas  systdMtIquament  sur  des  autonatlsmas.  C'est  au  pllote  d'apprdder  ces  solutions 
at  da  las  sulvre  ou  d'autorlser  des  autonatlsmas  s'll  I'estlme  ndcassaire  ou  s'tl  n'a  pas  1e  temps  de  faire 
mieux. 

Un  SE  est  done  constrult  pour  un  expert  capable  d’apprdder  1a  solution  proposde  at  non  pour  un 

profane . 


D'autres  difficultds  rdsident  dans  la  recuell  de  rexpertlsa  ; 

-  ce  recuell  est  assurd  en  falsant  Interroger  das  experts  par  des  spddallstes  (an  gdndral 
psychologues)  ca  qui  est  un  travail  long  at  fastidleux  demandant  une  totala  disponibllltd 
das  experts, 

-  la  fomallsatlon  des  connal ssances  sous  forme  de  rdglas  llmltdes  en  nonbra  n'est  pas  una 
tbcha  alsde, 

-  ?a  transmission  de  la  connalssance  par  les  experts  se  heurte  parfols  b  des  obstacles  psy- 
chologlques  de  rafus, 

-  enfin  se  posent  les  probldnws  de  propridtd,  da  protection  at  da  non-divulgation  de  I'ex- 
pertlse. 

Pour  ces  raisons  II  faut  accorder  da  I'lmportance  au  ddval opponent  das  techniques  de  gdnie 
cognitique  (spdclallsd  dans  1e  recuell  des  connal ssances). 

2.5  -  Les  techniques  b  ddvelopper 

Pour  rdpondre  aux  besolns  des  utlllsateurs  en  natidre  d'lA,  11  convient  done  de  connaltre 
les  techniques  qui  dolvent  encore  prooresser  ; 

-  amdlloratlon  des  logiclels,  traltement  symbollque  des  falts,  langages  adaptds  b  I'lA, 

-  ralsonnement  sur  I'lncertaln,  logiques  floues,  concepts  da  possible  et  da  ndeessaire, 

-  rapidltd  d'exdcutlon  b  amdllorer  pour  attdndre  la  temps  r(e1. 


-  calculateurs  sp<c1f1qu*s  lA,  aiibarqitabllltA. 

-  cipaclU  dcs  ataoircs  4c  aasse, 

-  traltcacnt  4c  1c  prIorltA. 

-  cooptrctlon  cntrc  plusicurs  SE. 

-  fonullMtlon  4e  1c  connclsscncc.  p<n1c  cognitiquc,  cpprentl sscge  autonctlque. 


3  -  LES  soumag 

Lc  trcvcll  4u  rcsponscblc  4c  I ‘ccprccslon  4u  bcsoin  cn  Etct-ncjor  sc  hcurte  couraancnt, 
conac  nous  I'cvons  vu.  A  4e  noabrcuscs  41ff1cu1t4s  pour  prtvolr  Ics  conOUIons  4cn:  Icsqucllcs  s'cxAcu- 
tcront  Ics  alsslons  4cns  I'cvcnlr. 

Qucn4  CCS  conOltlons  font  cn  plus  appci  aux  techniques  4e  VIA,  ces  41ff1cu1t4s  sont  aggravAes 
par  4es  1ncert1tu4as  4ucs  A  une  Inforaatlon  Insuffisante,  4onc  A  une  ajconnal ssance  4es  problAaes  et  4e  leurs 
solutions  potcntlelles.  et  A  unc  organisation  1na4apt<e. 

Les  4oaa1nes  qui  solvent  4o1vent  4onc  faire  1'objet  4'un  effort  particuller  4c  la  part  4es 

Etat-aajors. 

3.1  -  Choix  4cs  applications  lA 

Pour  (tre  a4apt4c  au  traltcacnt  par  les  techniques  lA,  une  application  4o1t  r4pon4re  A 
plusleurs  crItAres. 

Tout  4'abor4  1e  problAae  A  traitor  ; 

-  4o1t  ttre  sufflsaaaent  coaplexe, 

-  ne  4o1t  pas  avoir  4e  solution  algorlthalque,  ou  cette  solution  4o1t  4eaan4er  un  temps  4e 
calcul  excessif, 

-  ne  4o1t  pas  avoir  4e  solution  Intuitive. 

•  est  partIcullAreaent  1n41qu<  si  les  Informations  sont  IncoaplAtes  ou  ImprAcIses, 

-  est  Agaleaent  1n41qu4  si  les  rAgles  4e  la  base  4e  connalssances  Avoluent  rap14eaent. 

Ensulte  1e  recuell  4e  I'expertlse  : 

-  4o1t  (tre  effectuA  auprAs  4e  praticlens  exp(r1ment(s, 

-  et  ces  praticlens  4o1vent  (tre  totaleaent  41spon1b1es. 

3.2  -  Mattrlser  les  SE 

La  mattrlse  4es  SE  ne  sera  effective  que  si  les  responsables  en  Etat-major  sont  consclents  4'un 
certain  noabre  4e  problAaes. 

-  Cotmie  nous  I'avons  vu  pr(c(4ennent.  un  SE  n'a  4e  valeur  que  s'11  est  r(a11s(  pour  (tre  utl- 
11s<  par  un  expert  pouvant  le  contrSler  et  non  par  un  profane. 

•  II  faut  savoir  aesurer  ses  ai^ltlons  :  un  SE  41sposant  4‘une  centalne  4e  rAgles  est  un 
optlaun  auJourO'hul.  En  particuller  la  realisation  4'un  "copllote  dectronlque"  ne  pourra 
se  faire  qu'A  travers  une  approche  pru4ente  par  'petlts  pas'. 

-  II  faut  savoir  trouver  les  concepteurs  les  plus  coapAtents  pour  le  SE  envIsagA.  La  coapA- 
tence  4ans  les  techniques  lA  est  en  effet  souvent  trAs  41vers1f1Ae  :  unIversItAs,  organisaes 
4e  recherche  Atatiques.  1n4ustr1e1s. 

-  La  realisation  4'un  SE  reprAsente  en  gAnAral  un  coOt  IlnItA  au  riAveloppeaent.  En  revanche 
les  4Ala1s  4e  mise  au  point  peuvent  (tre  trAs  laportants. 

-  Les  simulations  ollotAes.  4AJA  essentlelles  pour  le  4Avel oppeaent  4es  systAaes  4'araes, 
4ev1ennent  indls^nsables  pour  la  alse  au  point  4es  systAaes  experts  eabarquAs. 

-  Ce  sont  les  utlllsateurs.  et  non  les  1n4ustr1e1s,  qui  4o1vent  (tre  responsables  4e  la  mal- 
trlse  4e  la  partle  expertise.  Pour  cela  11  faut  Olsposer  4e  personnels  totaleaent  41spon1b1es. 

-  Les  utlllsateurs  4o1vent  Agaleaent  faire  Avoluer  eux-a(aes  la  base  4es  connalssances. 

-  II  faut  4onc  que  les  utlllsateurs  4isposent  4'une  organisation  a4aptAe. 

3.3  -  Une  oroanisatlon  aAaotAe 

Cette  organisation  4o1t  (tre  capable  4e  rAsou4re  les  problAaes  4e  coapAtence  et  4e  recuell 
4e  I'expertlse. 


U  coap^tence  doU  (tre  assurde  par  la  fonutfon  M  des  personnels  solvents  : 

-  au  niveau  de  I'Etat-auJor.  responsable  des  propraanes,  one  douipe  lA  ccMdKisde  d'of- 
flclers  de  diffdrentes  spdclalltds, 

-  dans  les  organlsaas  d'essai,  d'dvaluatlon  et  d'expdrlnentatlon,  au  anlns  un  officler 
coapdtent  dans  cheque  organIsiK. 

Coaaie  nous  I'avons  vu.  le  recuel)  de  I ‘expertise  constitue  une  charge  de  travail  lapor- 
tante  et  requiert  une  totale  disponibllltd.  Ce  recuell  dolt  (tre  : 

-  ordonnd  et  dirigd  par  1'dqulpe  lA  de  I'Etat-aiaJor,  directrice  des  prograames. 

-  rdallsd  par  des  experts  cholsis  et  disponibles  sous  la  responsabllltd  des  officlers 
coapdtents  dans  les  diffdrents  organisaies. 

Par  allleurs.  les  problfanes  de  protection  de  1'expertlse  dolvent  (tre  traltds  par  1'dqulpe 
lA  de  1 'Etat-major. 


4  -  caiciLUSiai 

Les  techniques  de  I'lntelllgence  artlflclelle  portent  en  elles  un  potentlel  considdrable 
d'efficacltd  pour  les  Htdrlels  adronautiques  allltalres  du  futur. 

Le  responsable  de  1 'expression  du  besoln  en  Etat-najor  dolt  en  tenlr  conpte,  ce  qui  Impllque 
des  actions  en  natKre  d'acquisitlon  de  la  conqidtence  et  d'organisatlon  pour  que  les  choix  correspondents 
et  le  sulvl  des  rdallsatlons  solent  effectuds  correctenent. 
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This  paper  explains  how  the  uae  of  correct  coaputer  hardware  can  be  used  to  Increase  programoer 
productivity.  It  uses  an  Air  Force  prograa  for  apecific  Inforaation  and  exaaplea. 


TRAOITIOIfAL  PRODUCTIVITY  VIEWS 

When  one  thinks  about  software  productivity,  one  tends  to  think  about  the  Bore  traditional  aethods 
of  increaalng  productivity;  high-powered  software  tools  coupled  with  high-powered  coaputers.  Syntax 
directed  editors  for  aost  languages  have  been  around  for  a  long  tiae  now.  Prograa  generators  have  becoae 
alaost  coaaonplace.  Even  a  popular  $39.95  Pascal  coapllar  that  has  several  screen-entry  prograa  generators 
available. 

Recently,  there  has  been  a  new  wave  of  software  productivity  tools.  They  all  use  very  sophisticated 
software  coupled  with  a  reasonably  high-powered  coaputer.  A  good  exaaple  is  the  Interactive  Ada 
Workstation  UAW)  which  General  Electric  is  developing  for  the  Air  Force.  This  software  developaent  tool 
constructs  a  ccapllable  Ada  prograa  with  the  aid  of  graphical  representations  (e.g.  finite  state  machines 
and  Buhr  diagraas).  The  lAW  runs  on  a  $100,000  per  user  lisp  processor.  The  productivity  gain  of  the  lAW 
is  eatiaated  to  be  at  least  one  order  of  aagnitude  beyond  ordinary  software  engineering  techniques.  This 
is  an  effective  tool  to  assist  in  software  productivity  increases;  but,  it  still  fits  the  traditional 
high-powered  computer  running  a  high-powered  program. 

What  happens  when  a  prograaaer  uses  one  of  these  traditional  software  productivity  tools  to  prograa 
an  eabedded  computer?  This  is  where  the  problems  start  with  respect  to  traditional  software  productivity 
views.  From  the  outside,  it  looks  as  though  there  are  no  problems  at  all.  In  fact  there  can  be  enough 
problems  created  to  rip  apart  any  previous  notions  of  prograaming.  Let's  take  a  look  at  how  this  develops. 

First  there  is  the  super  software  development  tools.  Ada  has  several  features  which  are  conducive 
to  software  productivity  gains.  One  can  reuse  previously  written  code,  even  if  it  varies  slightly  from 
what  they  really  need,  through  the  use  of  generics.  Many  people  argue  that  reusing  code  in  the  avionics 
environment  is  not  practical.  However,  for  aany  other  applications  it  aakes  sense  and  will  save 
developaent  coats.  A  generic  package  for  doing  screen  aanlpulations  for  terminals  (which  is  used  in  alaost 
all  Ada  programs)  could  result  in  cost  savings  if  implemented  and  used.  It  is  doubtful  that  anyone  would 
(or  could)  argue  that  a  database  package  is  not  a  good  candidate  for  reusability.  Many  applications  are 
good  candidates  for  code  reusability. 

Another  powerful  feature  of  Ada  is  tasking.  True  tasking  can  be  very  powerful.  Ada  has  given  the 
prograaaer  the  flexibility  to  write  programs  that  run  siaultaneously  without  having  to  think  about  how 
tasks  are  scheduled  or  how  they  communicate,  as  is  required  in  other  languages;  that  is  built  into  Ada 
itself.  All  of  the  built  in  capabilities  of  Ada  Usking  also  causes  code  size  and  execution  speed 
problems.  Previously,  if  it  was  not  written  in  assembly  language,  the  tasking  feature  required  a  specially 
written  run-time  system  to  handle  its  intricacies  and  allow  reasonable  execution  speed.  The  problem  here 
seems  to  be  due  to  the  compiler  implementations. 

The  next  feature  of  Ada  ia  exception  handling.  Formerly,  a  prograaaer  had  to  write  exception 
handling  features  separately,  frequently  In  assembly  language.  Ada  does  not  require  that  the  programmer 
write  in  this  capability;  the  language  does  it  for  them.  The  problem  with  exception  handling,  however,  ia 
that  it  adds  overhead  to  nearly  all  of  the  other  features  that  Ada  provides.  During  every  procedure  call, 
for  Instance,  Ada  checks  for  any  imaginable  error  or  inconsistency.  Prograaaers  have  the  option  of  turning 
off  error  checking,  but  they  may  not  want  to. 

The  final  faature  (or  non-feature)  is  praciss  timing.  Ada  just  does  not  allow  for  it.  The 
programmer  is  not  allowed  to  foros  an  event  to  occur  at  a  apecific  time.  The  only  timing  feature  la  the 
delay  statement.  AMSI/HlL-STD-lSlSA  defines  the  delay  statement  in  the  following  manner;  "end  suspends 
further  execution  of  the  usk  that  executes  the  delay  statement,  for  at  least  the  duration  apeoified  by  the 
raaulting  value."  In  other  words,  "delay  at  least  this  long."  How  does  one  implement  the  cyclic  executive 
without  precise  delays?  Probably  in  asaeabler  or  a  sore  difficult  high-level  language  like  FORTRAN. 


•  -  Ada  Is  A  Ragistered  Tradamark  Of  The  U.S.  Oovernment  (Ada  Joint  Prograa  Office)  1 • 
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TTie  next  super  softwere  tool  Is  the  type  thet  reseables  the  Interactive  ACa  U^kstatlon  (lAW) 
■entloned  earlier.  It  doesn't  require  one  to  knou  a  particular  prograaning  language  (in  thla  eaae  it  is 
Ada)  in  order  to  develop  the  required  softuare.  All  you  need  to  know  la  the  PmIc  design  of  the  prograe. 
The  lAW  is  a  super  aoftuare  product*  but  If  It  were  not  running  on  a  super  coaputer  (1  aillion  instructions 
per  second  or  KIP)  per  user  it  would  not  be  nearly  as  useful  as  It  currently  is. 

Secondly  there  ia  the  super  coaputer.  TfM  definition  of  a  super  eoaputer,  in  this  context,  is  one 
that  is  capable  of  giving  the  prograaaer  a  reasonable  response  tlae  when  running  reasonably  aophistioated 
software.  It  has  been  found  that  prograaaer  pro^ctlvity  ia  directly  related  to  coaputer  response  tlae. 

The  response  tiae  should  be,  obviously,  as  short  as  possible.  It  should,  also,  be  consistent.  laaglne 
working  on  a  prograa  in  which  the  prograaaer  Just  instructed  the  coaputer  to  coaplle  a  prograa.  The  first 
tlae  it  was  coaplled  the  proapt  was  returned  in  two  alnutas.  The  prograaaer  then  finds  that  there  is  an 
error  in  the  logic  so  the  prograaaer  aust  edit  and  recoaplle  the  prograa.  This  tlee  the  coaputer  returns 
in  twenty  ainutes.  But,  it  was  expected  to  return  in  two.  The  prograaaer  aust  sit  end  wait  for  it  to 
return  with  no  idee  about  how  long  It  will  taka.  In  both  eaaaa  the  tlae  was  wasted.  These  are  Just  two 
reasons  that  aost  software  productivity  syateas  are  hoatad  on  a  super  coaputer.  Exaaplea  are  the  Lisp 
Machines,  Inc.  (LNl)  and  Syabolics  lisp  processors,  the  IBM  43t1,  the  DEC  VAX,  the  Sun  workstation  and  even 
the  IBM  AT. 


PROCIUMaNG  PRQOUCTIVITf  AND  EMBEDDED  (SMALL)  STSTEHS 

Everyone  concerned  with  Ada's  use  in  embedded  systems  knows  the  problems  with  using  Ads  in  that 
arena.  Actually  one  can't  blame  Ada;  the  problem  lies  with  the  particular  lapleaentstions  of  the 
compiler.  The  problem  is  ooapounded  when  using  the  MIL-STD-1750A  computer.  It  is  slow  when  compared  with 

the  auper  computers  aentloned  above.  The  175(^  computer  has  s  very  limited  memory  capacity.  Used  in 

embedded  systems,  the  1750A  coaputer  tends  to  bs  used  in  critical  real-time  systems  such  as  the  Advanced 
Taotlesl  Fighter  (ATF).  Pilots  lives  depend  on  the  effectiveness  of  the  computers  on  the  airplane. 

Knowing  how  ouch  memory  an  Ads  program  with  tasking  and  all  Its  associated  error  checking  and  correction 
requires,  as  well  as  the  processing  power  required,  one  tends  to  not  use  the  features  of  Ads  mentioned 
above  even  though  the  prooiae  is  great. 

So  what  does  one  do  if  one  wants  (or  Is  required)  to  use  Ada  to  program  embedded  systems.  Well, 
mostly,  only  use  the  parts  of  Ada  that  the  1750A  Is  capable  of  handling.  But  then  the  programmer  night  as 

well  have  used  FORTRAN;  hence  the  name  AdaTRAN.  When  programmers  can't  get  around  using  particular  Ads 

capabilities  they  are  forced  to  take  other  steps. 

There  is  a  lot  of  overhead  associated  with  Ads  tasking.  The  run-time  required  to  support  this 
feature  can  fill  a  lot  of  memory  that  the  1750A  Just  does  not  have.  However,  the  more  important  problem 
with  tasking  is  speed.  Task  switching  takes  a  lot  of  time  to  scocmpllsh.  Embedded  systems  are  not  the 
place  to  have  a  slow  task  switch.  Task  switching  in  cyclic  executives  frequently  happens  60  times  per 
second.  In  some  compiler  implementations  the  whole  duty  cycle  would  be  taken  up  with  task  switching,  not 
doing  any  processing.  Two  of  the  things  that  a  programmer  can  do  to  remedy  this  problem  are  Just  not  use 
Ada  tasking  or,  if  they  have  to  use  Ada,  (usually  the  case)  Just  rewrite  the  run-time  to  be  fast  enough  to 
be  usable,  Down  goes  the  productivity  rate. 

The  cyclic  executive  was  mentioned  above.  Ads  does  not  allow  for  the  cyclic  executive  which 
requiree  an  accurate  clock.  Ada  does  not  have  a  meana  for  accurate  timing.  One  must  modify  the  run-time 
again,  or  even  worse.  One  might  have  to  go  back  to  school  to  learn  different  schemes  to  control  the  system 
that  they  were  working  on.  Again,  down  goes  the  pr^^ducttvlty . 

Going  hand-ln-hand  with  the  cyclic  executive  problem  la  the  control  theory  problra.  Traditional 
control  algorithma  require  that  a  program  Implementation  have  access  to  precise  timing;  Ada  does  not  have 
1C<  Again,  it  is  back  to  school  or  the  drawing  board  to  modify  the  run-time  and  again  the  productivity 
suffers. 


Next  comes  the  idea  of  using  Ada  tasking  for  distributed  processing.  If  one  values  their  Job,  don't 
mention  this  Idea.  To  date  there  are  no  compilers  with  the  capability  to  produce  code  for  the  1750A  that 
allows  it  to  be  in  a  distributed  environment.  When  there  Is  one  available  It  will  be  for  a  specif io 
architecture;  probably  not  the  one  needed.  If  distributed  processing  using  Ada  is  an  absolute  must,  then  a 
lot  of  money  and  time  writing  a  compiler  (or  having  someone  else  write  it  for  you)  will  be  spent.  One  more 
time,  down  goes  the  productivity. 

Hopefully  by  now  l  am  sounding  a  little  like  a  broken  record.  You  are  also  probably  putting  two  and 
two  together  and  coming  up  with  the  idea  that  It  not  only  takes  auper  software  coupled  with  a  auper 
computer  to  maximize  software  productivity,  but  It  also  takes  a  target  computer  capable  of  handling  the 
language  features  that  ia  required  for  the  implementation. 


A  SOLUTION 

If  the  problem  Is  that  the  llmltattone  of  the  target  computer  results  In  tha  programmer  becoming 
lees  productive  when  writing  programs  what  ahwld,  be  done  about  it.  It  may  well  be  argued  that  the 
standards  must  be  changed.  Maybe  the  Ada  standard  should  be  changed.  There  are  those  who  advooete  that 
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th«  ooaput«r  standard  should  be  chan^sd;  use  a  aora  powerful  1750  ooaputer.  Still  others  say  that 

the  ailltary  should  use  a  ooapletely  different  ooaputer  standard.  Still  others  say  that  ida  should  be  used 
as  the  overriding  standard  and  allow  the  lapleaentor  to  ohooee  the  ooaputer  systea  that  can  handle  the 
lapleaentatlon.  The  answers  seea  to  be  pointing  in  the  sms  direction.  They  seea  to  be  saying  that  the 
super  productivity  tools  available  should  be  I'etaineds  it  is  the  hardware  that  aust  be  change. 

(hM  solution  is  to  siaply  to  change  the  1750As  to  beef  it  up.  This  aight  be  d<Hie  by  taking  the 
1750A  and  adding  the  required  hardware  (coprocessor  or  aooelerator)  to  give  it  the  required  capability  to 
allow  it  to  ooapete  with  the  super  coaputer.  Give  it  the  car-ability  to  do  the  things  that  the  executing 
Ada  prograa  noraally  does  very  slowly  in  software,  in  hardware.  Then  the  prograaaer  is  allowed  to  use  the 
pieces  of  Ada  that  can  Increase  their  productivity  without  thinking  about  the  hardware  iapleaentation. 


AM  EXAMPLE 

Recently,  the  Air  force  Mright  Aeronautical  Laboratories  (AfVAL)  had  a  contract  through  the  Saall 
Business  Innovative  Research  (SBIR)  office  to  do  an  Ada  prlaitives  study.  The  goal  was  to  find  out  how  to 
increase  the  speed  of  an  exeouting  Ada  prograa  by  looking  at  the  operating  systea  prlaitives  aost  used. 
Aaong  the  aethods  of  increasing  the  speed  reccaaended  was  the  Ada  coprocessor,  or  Ada  accelerator.  It 
would  serve  auch  like  the  aath  coprocessor  chip  does  cn  the  noraal  aicroccaputer  but  it  would  be  for  the 
specific  purpose  of  asking  Ada  run  faster. 

four  aaln  Ada  prlaitives  were  reccaaended  to  be  (ait  on  the  coprocessor  chip/board.  1)  Tasking 
nanageaent  and  switching.  This  area  holds  the  aost  proaise  for  speed  increase.  2)  Tiaer  services.  This 
would  add  a  capability  that  does  not  now  exist.  3)  List  aanipulation.  This  goes  along  with  task 
aanageaent.  4)  Heap  storage  aanageaent.  These  four  areas  will  be  discussed  in  greater  depth  later. 

The  aaln  suggestion  of  the  SBIR  was  to  build  a  coprocessor  board  or  chip.  The  coprocessor  would 
acccapany  a  Motorola  680(X).  Intel  8086/60286  or  1750a  based  systea.  The  coprocessor  should  be  designed  so 
that  it  can  be  transferred  froa  one  systea  to  another  as  easily  as  possible.  Once  the  hardware  has  been 
prototyped,  an  existing  Ada  coapiler  should  be  aodifled  to  produce  the  required  code  for  the  target  systea. 


PAYOff  (HARDWARE) 

The  SBIR  contractor  lapleaented  one  of  the  suggested  Ada  prlaitives  (list  aanipulation)  and 
slaulated  it  cn  a  silicon  coapiler.  Work  with  the  silicon  coapiler  deaonatrates  that  one  could  expect  a  16 
MHz  coprocessor  clock  rate  and  It  suggests  that  up  to  24  MHz  nay  be  possible.  The  siaulation  was  of  a 
staple  linked  list  fetch.  A  linked  list  software  exaaple  was  also  designed  and  lapleaented  in  C  on  an 
Intel  8088  developaent  systea  hosted  on  a  VAX  11/750.  ‘Hie  developaent  systea  emulator  was  then  used  to 
deteraine  the  nuaber  of  clock  cycles  required  for  each  Instruction.  This  data  was  used  to  estimated  the 
overall  tlalng.  The  results  were  quite  staggering. 

The  results  showed  that  auch  can  be  gained  using  a  coprocessor.  Using  a  5  MHz  central  processing 
unit  (CPU)  (like  the  IBM  PC)  with  a  5  MHz  coprocessor,  the  tiae  it  took  to  find  the  nth  block  whose  1th 
word  contains  a  specific  value  was  estlaated.  Using  loo  and  400  for  n,  it  was  found  that  the  silicon 
version  worked  an  average  of  167  tiaes  as  fast  as  the  software  version.  If  a  16  mz  coprocessor  is  used 
with  the  same  5  MHz  CPU  one  can  expect  a  speed  increase  of  over  500  tiaes.  Since  task  switching  is  much 
acre  ccaplex,  the  payoff  of  iapleaenting  it  in  silicon  could  potentially  result  in  a  higher  payoff.  Adding 
the  four  prlaitives  mentioned,  the  payoff  could  be  staggering  in  terms  both  hardware  performance  and 
software  productivity. 


PAYOPP  (SOFTWARE) 

Increase  in  software  productivity  resulting  froa  the  increase  in  hardware  performance  inevitable. 
With  the  increases  of  performance  in  existing  Ada  capabilities  coupled  with  the  addition  of  precise  timing 
^e  claims  many  advantages  over  traditional  aethods  of  Ada  programalng. 

The  largest  advantage  could  be  the  elimination  ot  the  need  to  rewrite  the  executive.  Since  tasking 
works  fast  enough  now  and  has  available  garbage  collection,  one  no  longer  needs  to  modify  the  existing 
executive  to  gain  these  advantages.  To  gain  speed  increases  in  tasking,  the  programmer  might  try  to  switch 
off  some  of  the  error  checking  that  Ada  automatically  uses  losing  some  of  '.he  programmer's  confidence  In 
the  program.  That  will  no  longer  need  to  happen. 

No  longer  will  the  prograaaer  be  forced  to  program  In  assembly  language  (at  least  ideally  not)  no 
(lerformanoe  critical  sections  of  code.  Studies  show  that  the  average  numbe*-  of  lines  of  code  per 
prograaaer  per  day  over  the  life  of  a  software  developaent  project  is  constant;  regardless  of  the 
prograaaing  language  being  used.  If  prograaaers  can  use  a  higher  percentage  of  Ada  and  a  smaller 
percentage  of  aaseabler,  the  amount  of  effective  work  that  each  line  of  software  does  has  increased.  An 
autoaatic  increase  in  productivity  is  realized. 

Another  benefit  is  that  the  programmer  does  not  have  to  learn  new  methods  of  control  theory. 
Generally,  control  theory  requires  that  one  knows  exact  tiaes  between  occurrences  of  events.  Ada  does  not 
support  this  capability.  Programmers  have  to  use  other  languages  or  different  control 


theories;  theories  that  are  not  faalllar  to  thee.  It  requires  thee  to  learo  the  different  theories  — 
taking  tlM  froB  the  project.  The  inclusion  of  hardware  supported  precise  tlalng  alleys  the  prograaser  to 
use  faalllar  ideas  and«  again,  will  result  In  increased  productivity. 

Allowing  a  prograaaer  to  use  Ada  with  no  other  language  alxed  In  results  In  another  great  benefit. 
It  Bakes  use  of  the  methodologies  that  the  designers  of  Ada  had  In  alnd,  Ada  was  created  with  many 
software  design  aethodologles  In  alnd  —  functional  decoaposltlon,  top-down  and  object  oriented  design 
being  three.  Taking  away  any  of  the  capabilities  of  Ada  requires  the  prograBoer  to  write  "kludges"  and 
"patches"  detracting  froa  the  readability,  supportability  and  Balntalnablllty  of  the  prograa.  Vhile  these 
three  advantages  do  not  fit  strictly  in  the  productivity  Bold,  they  do  fit  nicely  Into  another  mold  —  the 
life-cycle  cost  nold.  Mot  only  will  the  original  prograaaer  have  a  higher  productivity  rate,  the  person 
maintaining  the  program  will  also  have  a  higher  productivity  rate.  Maintenance  costs  are  particularly 
Important  since  maintenance  results  in  as  auch  as  95f  of  the  total  life-cycle  cost  of  the  software. 


CONCLUSION 

To  reiterate,  software  productivity  tools  have  evolved  to  a  very  high  state.  The  tools  are 
generally  associated  with  one  of  the  super  computer  defined  earlier  in  the  paper.  The  problem  arises  when 
the  programmer  can*t  use  all  of  the  facilities  of  the  language  because  of  the  limitations  of  the  target 
computer  (and  in  some  cases  the  llmltstlona  of  Uie  language). 

The  conclusion  la  very  simple:  In  order  to  achieve  and  maintain  a  high  software  productivity  rate, 
adequate  target  computers  are  needed  as  well  as  adequate  software  development  tools. 


ACRONYMS 


Ada . Not  an  acronym 

AFVAL . Air  Force  Wright  Aeronautical  Laboratories 

ATF. ............. .Advanced  Tactical  Fighter 

CPU, . * . Central  Processing  Unit 

lAH . .Interactive  Ada  Workstation 

NIP . Million  Instructions  Per  Second 


SBIR 


Small  Business  Innovative  Research 
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IXie  to  tbe  growing  conplexity  of  avionic  systaas^  the  develc^nent  cycle  for  mission  critical  software 
has  evolved  into  a  collective  process  of  organized  tasks.  Ihese  tasks  are  distinct  levels  of  effort 
idiich  eure  inplemented  by  the  devel^ser  to  ensure  the  creation  of  a  reliable,  (^rational  system.  Ihls 
paper  supmarizes  four  (^inciple  tasks  which  have  proven  to  be  excellent  procedures  for  developing 
avionics  software.  The  first  and  foremost  task  of  the  project  manager  is  to  establish  a  Configuration 
O>ntrol  Board  (OCB)  as  the  central  core  of  technical  managanent.  It  consists  of  a  groi^  of  key  hardware 
and  soft«mre  engineers  who  nutually  govern  the  status  of  system  develc^xnent,  and  incorporate  design 
changes  on  an  agreed^to  basis.  Itie  second  task  La  to  logically  separate  t^  software  project  into 
well-defined  phases  of  development.  Ihis,  too,  requires  the  cooperation  of  both  hardware  and  software 
teams  to  iiork  together  in  accordance  with  a  master  schedule.  The  third  task  is  to  create  ao)  automated 
data  base  which  contains  the  latest  interface  specifications  (ICDs)  and  system  message  definitions  for 
use  by  the  engineers.  Finally,  the  last  task  is  to  procure  hardware  emulators  and  stand-alme  test 
stations  as  an  effective  means  of  testing  software  prior  to  system  integration  and  test  (ICtT). 


iimooacriQH 

Ekje  to  the  growing  coi^lexity  of  avionic  systaas,  the  development  cycle  for  mission  critical  software  has 
beccme  more  Involved  in  berms  of  the  difficulty  and  nURibec  of  software,  interface,  and  test  requirements 
to  be  defined.  Consequently,  the  probability  of  incurring  design/coding  errors  is  increas^  due  to 
written  and  verbal  mlsconmunications  between  the  hardware  and  software  development  groups,  information 
latencies  due  to  the  nonber  of  developers  involved,  and  inadequate  software  testing  prior  to  system  I4T, 
In  order  to  help  minimize  the  aforementioned  problars,  it  was  necessary  to  create  several  guidelines 
t^ich  1)  enforce  a  fotiMl  comnunication  network  between  the  hardware  and  software  groups;  2)  9>hance 
the  visibility  of  ^oltware  progress;  3)  iiaprove  information  access;  and  4)  enhance  the  software 
verification  process.  These  guidelines  evolved  into  four  specific  tasks  i«#>ich  are  addressed  in  the 
following  paragraphs. 


The  first  task  is  to  establish  a  Configuration  Control  Board  (COB)  **iich  enforces  a  formal  comnunication 
netwsck  between  the  hardware  and  software  development  groups.  The  Board  consists  of  Key  engineers  and 
managers  from  both  disciplines  mutually  govern  the  status  of  the  system  and  incorporate  design 
changes  on  an  agreed-to  basis.  They  attend  all  formal  design  reviews  euid  major  design  walk-throughs  to 
ensure  that  neither  gtoi?»  is  being  compromised.  They  also  meet  on  a  weekly  basis  to  review  the  current 
state  of  the  system  and  examine  design  problem  reports  idiich  are  generated  throughout  the  development 
effort  (i.e.,  from  requirements  definition  to  system  UT).  Finally,  all  design-related  issues  arc 
properly  docmented  and  reviewed  by  the  OCB  before  any  changes  are  officially  made  to  either  the  hardware 
or  software  designs. 


The  second  task  is  to  divide  the  software  project  into  six  logical  phases  of  developoent: 

1)  Software  Requirements  Definition 

2)  ’^Dp-Level  and  Detailed  Design 

3)  Module  Code  and  'Pest 

4)  Component  UT 

5}  Configuration  Item  I&T 
6)  System  UT 

The  first  phase  is  to  define  the  software  requirements  in  relation^ip  to  tlie  hardware  requirements  to 
ensure  that  design  oversites  are  not  incurred.  Additionally,  this  phase  must  be  coripleted  prior  to 
starting  the  second  phase  in  order  to  est^li^  a  known  baseline  of  requirements. 

The  second  phase  mandates  the  satisfactory  completion  of  all  of  the  software  design  reviews  and  walk¬ 
throughs  prior  to  coding  the  software.  Work  folders  are  then  established  ^ich  contain  all  of  the  soft- 
Mre  material  pertaining  to  a  particular  processing  element  called  a  configuration  item  (e.  g., 
data  processors  and  signal  processors  are  two  separate  configuration  items) .  Bxenples  of  data  recorded 
in  the  work  folder  include  software  requirements,  top-level  and  detailed  design  descriptions,  walk¬ 
through  results,  source  listings,  module  code  and  test  history*  coirponent  and  configuration  item  I6T 
history,  and  design  problem  reports. 

The  third  phase  re^iires  that  each  software  function  be  developed  in  a  modular  fashion  and  tested  accord¬ 
ingly  (i.e.,  a  module  is  defined  as  being  a  email  con^illable  file  i^ich  performs  a  single  function  in  an 
efficient  mannet)  •  In  addition,  module  developoent  is  typically  petfoimed  on  a  mainframe  conputer  so 
that  the  programmer  can  take  advantage  of  various  sgpport  tools  such  as  the  Scenario  Qsnerator/Monitor, 
the  ICD  data  base  and  <M>ugger8. 
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Once  each  oiodu'  e  meets  its  own  unique  perfoeaanoe  cequirenents,  then  software  development  transitions  to 
the  component  I&T  phase  where  a  set  of  related  modules  are  integrated  tested  aa  a  whole  entity. 
Again,  this  phase  of  developnent  takes  place  on  a  mainfrane  to  take  advantage  of  the  support  tools. 

the  next  phase  is  to  integrate  and  test  a  set  of  related  components  which  comprise  a  given  configuration 
itan.  This  develc^nent  takes  place  on  both  the  malnfrane  and  the  target  proce^^or  so  that  other  helpful 
tools  may  be  utilized  (e.g.,  the  hardware  esulator  which  resides  on  the  mainframe  and  the  stand-alone 
test  station  which  n  arfaces  to  the  ggocossor) .  Additionally,  the  developer  will  be  cible  to  assess  how 
well  the  software  runs  on  the  hardware  during  ^is  phase  of  develc^nent. 

The  final  phase  is  System  16T,  whereby  the  configuration  items  are  integrated  together  to  create  individ¬ 
ual  threads  of  operation.  This  is  the  final  and  most  difficult  stage  of  software  developnent  since  it 
involves  the  integration  of  several  unique  hardware  and  software  elements. 

In  sunnary,  these  software  developnent  phases  have  proven  to  be  excellent  procedures  for  developing 
software  while,  at  the  same  time,  enhancing  program  visibility  and  control. 

nSK  3:  AimMKTB)  lO)  Dm  bASB 

The  use  of  an  automated  ICD  data  base  is  beneficial  to  the  user  in  several  respects.  By  its  very  nature, 
it  is  readily  available  to  anyone  who  has  the  appropriate  need-to-know  authorization  to  access  the  host 
conpater  ^ich  supports  the  toolset.  The  data  base  also  contains  a  detailed  description  of  every  message 
and  ICD  used  within  the  system.  Therefore,  vnritten  and  verbal  misconniunlcations  between  the  various 
development  groups  are  effectively  minimized,  if  not  totally  eliminated. 

The  data  base  is  maintained  by  the  OCB  on  a  weekly  basis.  Any  pressed  changes  to  the  baselined  hardware 
or  software  designs  are  always  documented  in  design  preplan  reports  and  formally  reviewed  by  the  OCB.  If 
approval  is  granted,  then  the  data  base  is  updated  by  the  OCB  to  reflect  these  modifications. 

In  conclusion,  the  automated  data  base  is  an  invaluable  source  of  design/interface  data  because  it  is 
readily  accessible  to  all  users  and  provides  current  information. 

nsK  4:  soracuB  nsr  aiviioiwr 

Ihe  following  teat  environments  were  chosen  since  they  verify  three  aspects  of  software  design,  namely 
the  softvmre-to-software  interfaces,  the  hardware-to-software  interfaces,  and  real-time  operation. 

Scenario  generators  and  monitors  are  useful  software  programs  which  are  used  to  stimulate  the  software 
packages  while  monitoring  the  message  traffic  between  the  software  modules  (i.e.,  software-to-software 
interface).  Hence,  the  developer  can  easily  test  the  software  with  a  number  of  possible  scenarios  and 
examine  ti«  resultant  messages. 

Hardware  emulators  are  also  useful  software  programs  which  emulate  the  operational  characteristics  of  the 
host  processor.  This  is  beneficial  in  determining  the  validity  of  the  software  algorithm  in  relation  to 
the  processor's  capabilities  and  limitations  (i.e*,  hardware-to-software  interface). 

Finally,  the  stand-alone  test  stations  are  wique  hardware  environments  \4iich  are  used  to  debug  the 
software  during  real-time  operation.  This,  too,  is  an  invaluable  tool  since  It  permits  the  developer  to 
examine  the  results  from  individual  software  instructions  during  actual  execution  times. 

ccmjjsvM 

With  the  advent  of  highly  progran«table  systans,  there  surfaced  a  need  within  the  avionics  conmunity  to 
establish  guidelines  which  definitised  the  relaticxi^ip  between  hardware  and  software  developnent  ef¬ 
forts.  These  guidelines  evolved  into  four  specific  tasks  which  ensure  that:  1)  design  oversites  are 
minimized;  2)  software  progress  is  controlled;  3)  critical  interface  definitions  are  readily  avail¬ 
able;  and  4)  software  is  fully  tested  prior  to  system  UT.  It  is  believed,  therefore,  that  the  combined 
implementation  of  all  four  tasks  will  ensure  the  developnent  of  a  reliable,  operational  system. 
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ABSTRACT 


High  capacity  data  processing  architectures  are  now  available  in 
avionics.  The  development  of  embedded  software  has  become  a  major 
activity  in  most  avionics  Equipment  manufacturing  Companies. 

These  companies  are  faced  with  challenges.  They  have  to  master  the 
quickly  evolving  software  technology  and  to  develop  the  associated 
know-how.  They  must  also  face  a  change  in  the  internal  economic 
structure  of  the  company  and  in  the  financial  relationship  with  the 
customer  resulting  from  the  increased  incorporation  of  software  in  the 
equipment . 

Some  features  inherent  in  the  software  reinforce  the  idea  that  changes 
in  the  functions  performed  by  an  equlpement  will  be  implemented  more 
easily.  Hany  customers  ask  for  facilities  allowing  them  to  modify 
software  themselves.  These  requests  often  result  from  the  customer's 
desire  to  acquire  a  degree  of  independence  with  respect  to  the 
manufacturer. 

To  meet  these  requirements,  the  manufacturer's  position  has  to  satisfy 
different,  and  sometimes  contradictory,  conditions  : 

.  the  desire  to  keep  meeting  customer's  needs, 

.  the  need  to  maintain  eind  improve  a  technologically  leading  position 
and  to  ensure  adequate  financial  resources, 

.  the  need  to  maintain  and  improve  its  own  image. 

The  first  part  of  the  paper  is  a  tentative  answer  to  the  following 
questions  : 

.  what  characterizes  the  development  of  an  equipment  which  includes 
software  :  types  of  software,  activities,  tasks,  skills,  facilities. 

.  why  are  software  modifications  equivalent  to  a  partial  redevelopment 
and  where  do  the  difficulties  lie, 

.  what  are  the  conditions  under  which  a  customer  may  modlfiy  the 
software  of  an  equipment. 

The  second  part  of  the  paper  provides  the  answer  to  some  aspects  of  the 
process  of  giving  a  user  the  autonomy  to  perform  software 
modifications . 


6-2 


PAHT  1 


1  -  SOME  CHARACTERISTICS  THAT  INFUIEWCE  SOFTWARE  IN  AVIONICS 


Software  Incorporated  in  on-board  military  equipment  or  systems 
generally  has  to  work  within  tight  constraints.  According  to  the 
definition  in  (BOEHM  8l)  this  software  must  operate  in  a  strongly 
coupled  complex  of  hardware,  software  and  operational  procedures. 

The  requirements  of  the  equlpements  and  systems,  expressed  in  terms 
of  maximum  volume,  weight,  power  dissipation,  performance,  and 
functional  complexity,  result  in  severe  constraints. 

The  final  definition  of  the  embedded  software  results  from 
optimization  of  the  design  of  the  equipment  or  system  in  order  to 
satisfy  as  far  as  possible  the  preceding  constraints. 

The  long  operational  life  of  equipment  and  systems  is  another 
factor  which  greatly  impacts  the  definition  of  software  :  the  cost 
of  changing  the  hardware  is  so  hig^»  that  the  software  is  expected 
wherever  possible  to  handle  the  changes  whatever  their  origin 
(problem  solving  or  functional  updating). 


2  -  PARADIGM  FOR  THE  DEVELOPMENT  OF  THE  SOFTWARE  OF  AN  EQUIPMENT 


The  waterfall  model  of  software  life-cycle  has  been  widely 
described  ([ROYCE  70],  [BOEHM  8l])  and  is  still  a  reference.  A 
useful  variant  of  the  model  considers  that  the  integration  and 
test  phase  should  be  divided  into  sub-phases.  Each  of  these  sub¬ 
phases  is  assigned  a  precise  objective  of  verification  and 
validation  of  the  results  of  a  corresponding  analysis  or  design 
activity.  This  variant  model  is  in  the  shape  of  a  capital  V. 

All  these  models  apply  to  the  development  of  embedded  software 
except  for  one  characteristic  : 

the  software  is  not  the  final 
product,  but  only  part  of 
the  whole  equipment  or  system. 

The  avionics  equipment  or  system  manufacturer  needs  a  broader  model 
applicable  in  the  development  of  systems.  This  model  may  be 
obtained  by  extending  the  previously  introduced  V  form  software 
life-cycle. 

A  useful  example  of  sucl.  a  model  has  been  introduced  by  [ITI  85] 
(see  figure  1). 

The  activities  involved  in  the  development  of  an  equipment  may  be 
concisely  defined  as  follows  : 

.  Equipment  Requirements  analysis 

-  consists  of  determination,  specification  and  review  of 
equipment  functional,  performance,  interface  and  verification 
requirements , 


-  Results  in  : 


.  approved,  validated  equipment  requirement  specifications 
validated  for  completeness,  consistency,  testability, 
feasibility, 

.  approved,  validated  concept  of  operation  including 
preliminary  user's  manual, 

.  development  plan  :  milestones,  resources,  organization, 
responsibilities,  activities,  techniques,  products, 

.  control  plan  :  configuration  management  plan,  quality 
Assurance  plan,  overall  test  plan, 

.  definition  of  overall  and  in-flight  tests. 

.  Equipment  Design  phase 

-  Consists  of  :  determination,  specification  and  review  of 
hardware-software  architecture, 

-  Results  in  : 

.  validated  equipment  design  specification  :  hardware, 
software,  hardware  -  software  interface  specification, 
verified  for  completeness,  consistency,  feasibility  and 
traceability  to  requirements, 

.  identification  of  high-risk  development  Issues, 

.  preliminary  Integration  and  test  plans. 

.  definition  of  needed  specific  testing  equipments. 

-  NOTES  : 

The  software  definition  clearly  appears  as  the  result  of  an 
equipment  design  activity. 

Due  to  the  optimization  process  introduced  in  paragpraph  1,  the 
equipment  or  system  design  activity  is  carried  out  with 
iterations.  In  many  cases,  a  partial  prototype  must  be  built  for 
feasibility  study  purposes. 

The  design  decisions  made  during  this  phase  are  very  Important 
and  must  be  carefully  documented  in  order  to  ensure  their 
traceability. 


3  -  TYPES  OF  SOFTWARE  INCLUDED  IN  AN  EQUIPMENT 


The  software  included  in  an  equipment  or  a  system  typically 
perform  functions  related  to  : 


A  -  signal  processing, 

B  -  control  of  the  equipment  or  of  the  system. 
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C  -  Information  processing. 

In  the  A  and  B  fields  and  to  a  lesser  extent  in  the  C  field,  the 
definition  of  the  software  is  strongly  affected  by  the 
constraints  and  by  the  optimization  process  which  have  been 
introduced  previously. 

In  some  parts  of  the  B  field  and  in  the  C  field,  the  definition  of 
the  software  may  be  more  easily  related  to  the  operational  purpose 
of  the  equipment  or  of  the  system. 

Two  types  of  software  can  be  distinguish  ed  : 

.  Embedded  firmware  is  characterized  among  others  things  by  the 

following  features  : 

-  the  functions  performed  suit  the  hardware  and  are  often 
related  to  physical  effects  :  the  choice  of  data  organization 
and  algorithms  is  based  on  thoroue^  scientific  and 
experimental  knowledge  and  know-how, 

-  the  implementation  often  requires  the  use  of  microprogramming, 
assembly  language,  optimization.  The  result  is  a  combination 
of  a  hardware  device  and  software  that  lies  as  read  only 
software  on  the  hardware  device. 

.  operational  software 

-  the  functions  performed  suit  the  user's  operational 
requirements.  Operational  Information  rather  than  primary  data 
is  manipulated.  The  choice  of  data  organization  and  algorithms 
also  requires  thorough  knowledge  and  experience,  but  these  are 
easier  to  transfer, 

-  the  implementation  is  based  on  the  use  of  a  higher  order 
language.  It  is  less  hardware  dependent  and  more  subject  to 
changes . 


4  -  ABOUT  TESTING 


In  most  cases,  the  critic! ty  of  the  functions  performed  by  the 
equipment  or  sytem  result  at  software  level  in  severe  testing 
requirements . 

The  main  difference  with  the  development  of  non-embedded  software 
lies  in  the  need  for  particular  instrumentation  and/or  of  specific 
test  equipments. 

In  general,  these  test  equipments  are  software  driven.  This 
software  depends  on  : 

.  the  architecture  of  the  test  equipment, 

.  the  functions  to  be  tested  (black  box  testing) , 

.  the  organization  of  the  equipment  or  system  to  be  tested  (white 
box  testing) . 


6-5 


It  follows  that  any  aodification  of  the  functional  definition 
and/or  the  design  of  the  equipaent  will  have  a  significant  Impact 
on  the  definition  of  the  software  of  the  test  equipments. 

Testing  is  an  activity  essenticdly  oriented  towards  detection  of 
failures  and  defects,  the  goal  being  to  ensure  correctness  and 
reliability  [TURING  50]  [BRANDSTAD  80]. 

Once  an  error  is  detected.it  must  be  fixed.  Real  time  aspects  make 
this  activity  difficult  and  most  often  some  special  instrumentation 
is  required. 

This  overall  activity  must  be  carefully  managed  under  two  aspects  : 
.  configuration  management, 

.  identification  and  updating  of  a  convenient  subset  of  test  data 
(the  non-regression  subset),  the  goal  being  to  check  for 
undesirable  effects  of  modifications  without  re-executing  all 
tests  previously  executed. 

5  -  ABOUT  SOFTWARE  DEVELOPHEWT  FACILITIES 


These  facilities  consist  of  computers  and  software  tools. 

Their  role  is  to  help  the  developer  in  the  various  aspects  of  his 
activity  : 

.  technical  aspects  :  e.g.  :  design  tools,  compilers,  generators, 

.  documentation  tools, 

.  management  tools, 

.  librarians,  long  term  storage... 

These  tools  are  mainly  software  tools.  They  may  be  updated  and  this 
results  in  specific  software  engineering  activity  : 

.  configuration  management  of  tools, 

.  determination  of  the  tests  to  be  performed  in  order  to  decide 
whether  or  not  a  new  release  of  a  software  engineering  tool  may 
be  used  to  modify  a  product  of  an  earlier  release. 


6  -  ABOUT  KNOWLEDGE.  SKILLS  AND  KNOW-HOW 


The  equipment  manufacturer  must  carry  out  development  activities 
for  his  own  use  and  increase  his  knowledge  and  know-how  in  a  lot  of 
areas.  Those  which  are  of  interest  here  are  : 

A  -  Operational  area 

e.g.  in  the  Electronic  Warfare  field  : 

.  general  and  theoretical  knowledge  concerning  detection 
tmalysis.  Jamming  techniques  and  coordination  as  well  as 
threats . 
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.  definition  of  operational  and  technical  requireaents . 

.  pre- flight  prepwatlon,  analysis  of  fli^t  report  readouts. 

B  -  Baulnwent  or  Ssstea  Dest^pi  and  Testlna 

.  design  techniques,  data  processing  architectures,  signal 
processing  algorlthss.  design  verification  and  validation 
techniques  (e.g.  sisulation.  prototyping...). 

.  equlpaent  and  systea  integration  and  testing  techniques, 
testing  equlpaents  design. 

.  in-flight  testing  techniques. 

C  -  Software  Enicineerinit 

.  Methods  and  techniques  used  to  support  the  software 
developaent  actlvltes  : 

Software  requlreaents  analysis 

Design  :  detemination  of  software  architecture,  program 
design  and  data  base  design. 

Programming. . . 

.  documentation  :  developaent  and  update  of  : 

-  user  documentation, 

-  development  and  maintenance  documentation. 

D  -  Facilities  swnageswnt 

.  operation  of  development  facilities, 

.  updating  of  tools  over  a  long  period  of  time, 

.  configuration  management  of  tools. 

6  -  RELATIONSHIP  BETWEEN  TYPES  OF  SOFTWARE  AND  KNOW-HOW 


TYPE 

KNOW-HOW 

FIRMWARE 

OPERATIONAL 

SOFTWARE 

OPERATIONAL  AREA 

♦ 

♦  ♦ 

EQUIPMENT  DESIGN 
&  TESTING 

♦  ♦  ♦ 

♦ 

SOFTWARE  ENGINEERING 

• 

• 

I 
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Noraal  skill  required 

*  Extensive  coupling  :  hlg^  skill  required 

**  Very  extensive  coupling  >  very  high  skill  required 

***  Extreaely  extensive  coupling  >  extreaely  hi^  skill  required 


7  -  ABOUT  THE  DOCmBHTATIOW  OF  SOTTHAHK 

The  very  sany  guides  and  standards  that  exist  iaplie  the 
necessity  for  a  large  quantity  of  documents  to  be  produced 
throu^out  the  whole  development  phase. 

All  this  documentation  is  very  useful  to  support  the  quality 
assurance  activities  as  well  as  the  development  activities. 

This  results  in  a  lot  of  cabinets  full  of  documentation  and  the 
question  is  ■;  How  really  useful  is  all  this  paper  (or  magnetic 
media)  to  support  updating  of  the  software  in  the  long  term 
perspective 

The  main  problem  concerning  the  documentation  lies  in  the  lack 
of  : 

.  completeness, 

.  readability  ;  it  is  a  matter  of  precision,  conciseness. 

The  many  modifications  made  during  the  development  phase 
especially  during  integration  and  testing,  affect  readability  as 
well  as  completeness. 

.  usefulnesss  :  the  documentation  should  not  only  describe  the 
software  architecture,  but  also  why  this  architecture  has  been 
chosen  and  how  it  has  been  tested.  Facilities  should  be 
provided  to  facilitate  access  to  a  given  Information. 

Most  often  the  required  information  exists,  but  is  distributed 
across  hundreds  of  pciges  of  documentation  resulting  in  low 
usefulness.  It  is  a  matter  of  documentation  and  presentation. 

Few  people  are  able  -or  want-  to  study  such  documentation,  and 
even  fewer  customers  are  willing  to  pay  the  real  price  for  it  ! 

The  documentation  should  be  elaborated  in  two  steps  : 

.  during  the  development  phase, 

.  at  the  end  of  the  development  phase,  a  maintenance  documentation 
should  be  elaborated  and  verified. 

As  this  documentation  is  bound  to  be  updated,  this  process  must  be 
aided  by  strong  methodologies  and  tools. 


8  -  CONCLDSIONS  OF  PART  1 


CONCLUSION  1  : 


The  conclusion  la  that  updating  of  flnware  Is  such  sore  difficult 
and  risky  to  bring  out  than  updating  of  operational  software  Is. 

Thus  the  equlpaent  aanufacturer's  position  is  that  only 
modifications  to  operational  software  are  to  be  proposed. 

CONCLUSION  2  : 

The  preparation  and  updating  of  the  maintenance  documentation  Is  a 
costly  process. 

The  resulting  documentation  Includes  a  large  amount  of  the 
manufacturer's  know-how.  It  leads  to  a  large  saving  in  maintenance 
costs.  Supplying  this  documentation  is  equivalent  to  a  know-how 
transfer.  Thus  the  aanufacturer's  position  Is  that  there  should  be 
a  negotiation  on  this  basis  at  contract  time. 


CONCLUSION  ^  ; 


Part  1  has  shown  that  any  Intervention  on  the  software  requires  the 
existence  In  the  user's  country  of  the  same  facilities  as  those  of 
the  manufacturer's  and  the  existence  of  the  appropriate  set  of 
skills. 

Even  if  the  manufacturer  cannot  accept  to  guarantee  the  results  of 
the  user's  Intervention,  his  desire  is  to  keep  meeting  customer's 
needs. 

The  only  solution  Is  to  aid  the  user  to  acquire  autonomy  through  a 
cooperation  process.  Because  this  process  implies  some  form  of 
technology  transfer,  it  will  be  designated  as  the  transfer  process. 

Part  2  provides  a  broad  definition  of  this  transfer  process  as  it 
applies  at  the  present  tine  between  THOMSON-CSF  and  some  of  its 
customers. 


-  THAWSFEH  PROCSSS 


The  purpose  Is  to  develop  autonomous  software  updating  capabilities  in 
the  customer's  country. 

The  process  involves  four  phases  : 

Phase  1  :  Transfer  requirement  analysis  and  definition  of  the 
cooperation  phase. 

Phase  2  :  Initialisation. 

Phase  3  :  Cooperation. 

Phase  4  ;  Autonomy. 


Phase  1  -  End  points 

.  approved,  validated  concepts  of  operation  of  the  original  equipment 
or  system, 

.  approved,  validated  identification  of  the  operational  software, 

,  definition  of  the  scope  of  concept  updating  permitted  by 
modification  of  the  operational  software, 

.  approved  choice  of  the  updating  to  be  undertaken  in  the  cooperation 
phase, 

.  approved  identification  of  the  currently  existing  human  resources  and 
know-how  in  the  customer's  country, 

.  approved  definition  of  the  necessary  additional  resources  (human, 
know-how,  computers,  instrumentation,  software,  engineering 
tools . . .) , 

.  approved  definition  of  the  training, 

.  approved  definition  of  the  additional  supplies  (development, 
documentation,  partial  and  overall  specific  testing  equipments  etc.}. 

.  approved  definition  of  the  top  level  co-development  plan,  including 
milestones,  resources,  responsibilities,  schedules  and  major 
activities,  overall  work-sharing  between  customer  and  manufacturer, 

.  approved  co-development  contract  based  on  the  above  items. 

Phase  2  -  End  points 

.  delivered  and  Installed  operational  equipment  or  system, 

.  completed  training  of  the  different  categories  of  personnel, 

.  completed  installation  of  the  additional  resources  identified  in 
phase  1  (software  development  center,  specific  testing  equipments, 
flight  testing  base . . . ) , 


I 
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.  approved,  validated  definition  of  the  equipnent  or  systen  updating 
to  be  developed  In  the  co-developaent  phase, 

.  approved,  validated  software  requlreaent  specification  :  functional, 
perfomance  specifications  validated  for  consistency,  testability  and 
feasibility  considering  the  existing  hardware  ~  software  interface  as 
a  constraint, 

.  detailed  developnent  plan  : 

-  milestones,  resources, 

-  organization  and  responsibilities.  Precise  details  of  work-sharing 
between  Customer's  and  manufacturer's  teams, 

-  activities,  schedules,  products, 

.  detailed  control  plan  :  configuration  management,  quality  assurance. 
Phase  ^  -  End  points  :  Completion  of  System  Acceptance  Review 


.  Concerning  the  software  : 

-  Satisfaction  of  software  Acceptance  tests. 

Verification  of  satisfaction  of  software  requirements. 

-  Acceptance  of  the  modified  deliverable  software  products  : 
documentation . 

.  Concerning  the  system  : 

Satisfaction  of  System  Acceptance  test  : 

-  verification  of  satisfaction  of  systems  requirements, 

-  verification  of  operational  readiness  of  system,  facilities  and 
personnel . 

Acceptance  of  the  modified  deliverable  system  products  :  hardware, 
software,  documentation,  training,  facilities. 

Completion  of  all  specified  conversion  and  installation  facilities. 
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DISCUSSION 


PJLTUhHn,UK 

I  submit  that  the  reasons  many  users  want  to  change  software  is  because  many  systems  are  so  inflexible  that  that  is  the 
only  way  to  make  changes.  Should  we  not  design  more  flexible  systems  that  can  be  operationally  reconfigured  without 
changing  the  software? 

Author’s  Reply 

Systems  may  be  designed  for  flexibility  only  as  br  as  we  are  able  to  foresee  them.  Unexpected  requirements  will  always 
cause  software  modifications.  However,  flexibility  should  be  considered  a  quality  factor. 


W.Urschcl,US 

Current  aircraft  systems  have  relatively  few  firmware  processors,  as  the  majority  of  vehicle  control  systems  are  analog 
or  hydro-mechanical.  However,  future  aircraft  promise  to  have  all  vehicle  control  systems  implemented  with  digital 
controls  and  the  total  sum  of  these  processors  may  outnumber  the  operational  software  processors.  How  do  you 
propose  to  support  the  firmware  software  with  thk  scenario? 

Author’s  Reply 

With  the  current  state  of  the  art,  the  recommendation  is  to  have  the  original  developer  accomplish  the  modification  of 
the  firmware  systems. 


M  Jacobsen,  Ge 

Can  you  comment  on  the  cost/efforts  related  to  software  know-how  transfer  to  another  party  in  relation  to  the  original 
development  cost? 

Author’s  Reply 

The  relative  costs  of  transfer  vary  for  each  program  because  they  depend  on  exactly  what  is  transferred  and  on  what 
commercial  aspects  are  involved.  Generally  the  transfer  process  implies  some  form  of  re-development.  The  efforts 
associated  with  this  re-development  are  of  the  same  order  of  magnitude  as  those  associated  with  the  initial 
development. 


MATTRISE  DES  LOGiCIELS  EMBARQUES 

par 


Monique  Slissa  et  Pierre  Villedieu 
Aerospatiale  —  Division  Helicopteres 
1 3725  Marignane  Cedes 
France 


1.  iHTnooucnow : 

Las  oondWons  MusMalles  acluelles,  assocMes  a  ravolution  des  systames  emtaiquas,  tom  qua  le  logicial  prend  una  placa  sans  casse 
plus  IfnpOftana,  wira  cdliqua,  dans  la  ddvaleppetnanl  dun  systama  avioniqua. 

Cast  pouiquol,  tavlonnaur,  Maitra-dOauvra  du  systama,  sa  doll  da  prandra  an  connpia  la  davaloppaniani  das  logiclels.  an  assuranl  la 
responsabMa  ainsi  quima  pan  das  acdviias  da  raalisation. 

Loblel  da  ealla  omiitiunlcamin  aa  da  Pfasanlaf  nkis  an  daiaa . 

-  las  conditions  Mustdalas. 

-  lastratagiaganaialsdumallrarfoauvrssysiains, 

-  la  poitiqua  da  davaloppsfnsnidu  logicial, 

-  ladaveloppainenidalogicialsafnbafquasarAarespatlalsOH. 

2.  EVOLUnOK  DU  COWTEXTE IWDUSTHIEL  : 

2.1.  OnniHia.aanatayatamaaacniatt 

Las  missions  a  rampHr  par  un  systama  sort  da  plus  an  plus  burdas  et  complexes  (polyvalence  des  apparails.  strategies  da  plus  an 
plus  evolueas. . .  II  s'eneua  done  una  oomplexilieation  itnponarae  des  fcnctions  operationneles  qua  la  systama  don  rOaiser. 

Gael  conduisant  a  un  niveau  dintegration  da  rinlonnallon  da  plus  an  plus  aieva.  ainsi  qu'a  una  gestion  da  mission  da  plus  an  plus 
oontplaxa  nacessHant  una  Integration  ciolssanta  des  oommandes  el  visualisation. 

Ilestavidantquacaspointsoonoourentaaccroaralcujcursplusfonementlasbesolnseniiaaeinentsalpar  la  mama  an  logicial 


Par  aleurs.  si  las  dasolns  oparationnels  augmentara,  las  budgets  Snpanis  na  suivant  pas  catta  milalion.  Da  mama,  las  series 
laslanl  pau  Importanlas  an  raison  das  codts  Imponanis  et  das  besolns  toujours  particullais,  pamcuKaremenl  dans  la  domains  das 

naioopiarea. 

Cad  sa  tradu*  par  la  nacessiia  da  devoir  parsonnallsar,  a  eftaqua  demands,  las  daveloppamsnls  pracadants. 

Cautra  part,  ainsi  qu'l  a  ata  msnilonna  au  S  2.1.,  las  logiciels  preimenl  da  plus  an  plus  dimportancs,  II  s’ensult  un  accroissemem 
das  codts  lalatis  adrs  matanel  at  logicisl.  quH  laul  done  amortir  sur  des  sanes  taHas  (voir  Hgura  1 ) . 


oodts  ralatifs 
antia  mstarial 

at  logidal 


nombia  d'unitas 


$ 
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On  voi  done  qu9  pour  <to8sMespeuimpoilanie8(<  I00).lftpoidsd6scoutsloolciel5,  suruneunil^.esttrte  important. 

ii  est  alors  ridcessairo,  iors  dtjne  appiicaPon,  d»  potAOir  Uiser  au  rnaxirnurn  ies  travaux  desddvetoppern^ils  ani^fieurs. 

Ceci  (^re,  (fautre  pad,  ta  pos$blH6  da  rMuira  tea  d6lais  da  davelopperrwnl  (Turta  nouveHa  application  at  augmenta  done  la 
competition  da  raviormatir. 

Oiganisar  la  rantabiiie  das  travaux  da  dMoppenwt  deviert  done  un  opjactif  maiaur. 

2X  CoMiQuanca  pour  ia  MaKra-tfOauwa : 

En  resume,  on  voN  done  qua  la  Mallra-tfOauvra  don  etre  rr^altra  das  coCHs  at  das  deiais  du  devaloppemant,  non  seutemem  pour 
rapplication  an  cours,  mats  egalamani  2  plus  long  tarma,  an  prevision  das  versions  dtirivees  uReri^ras.  pour  tesquelies  il  devra 
etra  erx»re  competittl. 

II  doR  done  maltrisar  ransampla  du  systems,  at  plus  padBuKeramant  las  logiciels  qui  suppodani  la  pRjs  grande  pad  das  evohitions 
du  systeme. 

CfltaluiirnDosadQricdernanfisefledevalQpQameftdeslDgciebpfenafSDadausvsietnesurlasasDaQssuivar^ 

•  Procedures  at  methodas  da  devaloppamers,  afin  da  pouvoir  assurer  las  aspa^  'caditicatbn'  das  logiciels. 

•  Possession  das  droits  <fusage  at  da  modification  IHrnitessur  las  produRslogictels. 

•  Gasiion  da  la  oontiguration  das  logiciels  afin  da  pouvoir  nuilrisar  las  evolutions  at  modlicalions 

Cette  strategia  nouvala  de  la  pad  du  Maitra-rfOauvre,  an  matiera  da  logicieis.  conduit  e  revidanca  e  finstauration  da  nouvelies 
relattons  antra  favionnaur  at  ses  sous-contractants.  Cad  ast  presante  plus  an  detaR  dans  las  paragraphes  suivants.  at  plus 
padiculierement  §  3  at  §  S.3. 


3.  STHATEGIE  GEMERALE  : 

il  oortvient  (out  <fabord,  da  precisarquals  sont  las  iondemeria  at  las  bases  da  la  strategia  generate  an  matiers  da  iogidels. 

Ceu«-d  tmuvant  leurs  Drinefaes  dans : 

•  las  Bans  antra  las  travaux  de  competence  'systeme*  at  las  travaux  iogidels*. 

-  las  caracterldiquas  padiculidres  das  differentas  fonctions  operationrwias  &  tralar. 

3.1.  Procasatflde  devaiopDement  svateme/toQlctd  : 

La  specification  efun  systSme  at  de  ses  constituants  ast  etablia  par  un  processus  da  d6(initbn  descandante.  EBa  ast  anhehie  e 
chaqueetapaatlasevabationsdeGomfMtudequipauvert  etrafailesperTnettenidas’assurerpasepasdesaooherence. 

Dans  un  premier  terrfis,  la  phase  de  predetinHlon  a  pour  but  retablissemani  das  spedticailons  generates  du  systeme  sur  la 
base  du  concept  choisi  par  le  Maltre^Oeuvre  pour  repondra  aux  exigences  operatbnneDes  issues  des  besoins  expnrrtes  du 
dbnf,  au  travars  des  missions  i  acoompffr. 

Les  sfteciTicatbns  techniquas  du  syst^.  des  sous  syst^mes  cfdquipaments  y  padidpant  sort  etabiias  au  cours  de  la  phase  de 
dMnHlon  proprement  die,  en  prenant  an  oorrpta  rensembfa  des  contraintes  imposdes  par  to  contrdto  industrief.  tos  clients. .  ■ 

Ces  travaux  conduisenl  k : 

•  ia  cteterminatbn  de  farchitecture  fonctbnnefla  du  systeme  en  d^mposant  tos  fonctbns  op^ratbnneltos  pr^demment 
recanoBes  jusqu*au  niveau  "^temantaire'  das  forBtions  dies  "systeme"  pouvant  dtre  enti&rement  mises  an  oeuvre  dans  un 
dqu|>ement. 

•  La  suparpositbn  de  Tarchitecture  fonctionnele  sur  Tarchitecture  mat^delto  du  systtime. 

•  La  caract^risatbn  du  systeme  en  ca  qui  conceme  to  tiabilitd,  la  s^rit^,  la  maintenabilit6.  .. 

La  ctefinition  acquisa  ast  ensuite  d^tailtoa.  Las  axigencas  bglctoltes  relatives  aux  fonctions  6tant  titabitos.  le  travan  des 

^ipas  logictolles  commence.  Comma  to  montre  ta  figure  2.  la  conceptbn  pr^liminaire  du  bgictol  des  ^ipemems  que  ravbnneur 
vaut  mattrisar  est  farta  d  padir  de  Tanafysa  das  axigerreas  logictolles.  Pendant  cas  travaux,  tos  comraimas  suivantas  induitas  par  la 
bgiciai  sont  dmisas  par  tos  ^ipas  "systeme*  qui  poursuivent  en  paraltoto  la  ctefinition  (totailtoe  (tallies  m^moire  at  puissance  da 
calcui  requises  parfimplaniation  das  fonctbns  bgi^les.  rrtocanismes  tamps  rtel.  contraintes  srtocViques, .  .) 

Cetto-d  doit  dtratermirtoa  quand  tos  bgicials  passant  dans  la  phase  de  realisation. 


dfTtnition  phaw* 

Pn4«rinitiQn  I 
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On  a  vu  pracMemmeni  qua  les  ivoUiona  antra  deux  systames  portaianl  eaaanliaianienl  sur  la  logiciel.  pour  atra  ptjs  conailel, 
on  Paul  dka  quUi  syatame  eat  (Mdva  dun  aulra  paf : 

-  ac4oir(ourelial(raqulpeinentssirni:tas.iaalisanlune8atjlelonaionnalia(senaaur,...)-aqulpeinants'mono-fonction’- 

-  nxxtilcatlon  dea  logiclala daa calculataure  pdncipaux.  canlialaani  pkialeuia  lonctiona  (calculateuis  da  gaation,...)  -  dquipamanta 
“rnuU-lonctiona'- 

H.yf«iaartnt«:deuxlvne8delr»»at»ianBaratlonneaeB: 

■  Foncdon  ln<MpandanM.lniplanaaadanalaaa<|uipamentamono-fenctlon. 

-  FoncUonaMaa.iniplantaeadanaleaaquIpaniantaniuM-tonclions. 

Chacun  da  caa  typea  da  toneliona  poasMa  daa  ctfactaiiadquea  paiticuliaiaa,  an  ionctbn  deaquetaa  la  stratagia  da 
daveloppanieni  du  MaltradOauvra,  aara  mcxuaa. 

^n^orajndapandan^: 

Laur  but  ptmcipal  ast  daiaborar  un  anaaraUa  dinlomiatlona. 

EHeaannlcafaaarislIaaeBoafleaooInlaauivanla: 

■  Stabiwadanaieteinpa.LauraapacincationaavoluanlpeudunaapplicatbnarauIre; 

-  Naceaaitanlunaavoir-fairaapacillciuaaundomainepanicutet 
FonMoKj^: 

Elaa  utaaanl  dea  xaonnatlona  an  prevenance  da  renaanibte  du  ayatama. 

Elea  tort  ttenccaraaariiiaw  par: 

-  Naceaaiiad'adaplatbn  dun  ayatama  a  un  autre, 

-  avokitlona  da  leuta  apaclllcationa  mama  au  eours  dun  davebppemant.  an  (onctlon  das  axigencas  cNents.  danalyses 
oparationnellea  oomptamentakea, .. . 

-  contiennantleaavair-fairespaciic|uaderavionneurainsiquaclea 

-  aiamentslnduatnelemenlconfidenllals. 


En  comaciiance  da  caa  caraciaristkiiea.  on  naiit  ctacomcoBaf  ores  lonclbna  an  deux  aninea : 

'  Leatondlanaliaaa'aanBiilea'.parrappottaiaatratagblnduatilelledaravbnnaur: 

■  Laafonctbnsaaae'non-aanstilea'. 

La  MallranfOauvra  dolt  done  parfailemani  malinser  la  davebppament  daa  bgbbis  dea  aqulpamanta  mjltl-fonctbna,  au  tiavers 
dune  poWiqua  da  davabppemanl  da  bgidal  atrbte.  mala  tien  comple  dea  cftfarancea  da  "aanaUlta'  antra  lea  fonetbna. 


4. 


POUTMUE  06  DEVELOPPaMEKT  HE  LOGICIEL  : 
4.1.  OttiCBli  du  MallrB-irOauvta : 


LeaobladllaaieravtannaixflxeasaDomaueenmallVedalnnirblBora.blenavidBmniera: 

-  LaraductbndeaooOtaaldeadaiaia, 

-  raugmantaUondalaqualiadeapredujtabgiclels. 


nraiMnTnvBnaoeiniellaiXdaixxiniiillrleaanibiiaaulvanlBa: 


-  RauMsaibndesprodulabgicbla. 


-  Mlnimiaatbndeailataiaadanaurpar: 


minimisatbn  du  nombra  da  modificalbna  at 'apriaaa  an  ooura  da  davabppemanl. 
.  mblmlaalbndu  nombra  defrauraraabUeleaaptaamlaaenaafvba. 

-  MalblaadebdaHrilliondaapreduilabgiciala. 


Caa  aclbna  aonl  mitas  an  praHqua  au  travara  duna  mtttiodologla  da  davabppemanl.  Lee  biiefdapendancaa  antra  caa 
(fliarenlea  notbna  aonl  aebamatMaangura  2,  pourbnnarunooneapida  >oduclMia  bgidala*. 
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FIGURE  3 


A2.  ConceoldeDKXfcictIvM: 
4.2.1.  R4utHtei>hiit4 


TracBtionnellement,  la  r6utiiisatk>n  de  logidels  est  synonyme  de  rdcup6ratton  de  code  source. 

Cette  id4e  est  trop  restrictrve,  la  r^utiKsation  de  iogicMs  pour  6tre  efficace.  doit  dtre  vue  comme  la  recuperation  de 
produits  issus  de  chaque  phase  du  deveioppement. 

Ainsi,  eelon  rinportance  dee  evolutions  demandees,  ie  taux  de  recuperation  des  produits  logidels  cTun  d6veloppemeri 
precedent  pourra  etre  adapte,  rob)ectif  etani  (Tavolr,  quellee  que  soient  les  evolutions  necessaires,  des  produits 
recuperables. 

Cedjmgc^  deso^r^ntes^idoivert  $trepr«es.^ncqm^^^  iejxo(%s^s^^wlogpemen^^  ; 

-  oetmitlondephasesclairemeniidentirieeserMeneurducyciededeveloppement. 

•  Oetinition  de  composants  togidels.  representant  les  etats  successifs  cTun  logiciel  (fapptication  e  chaque  phase  du 
developpement ; 

•  Oermition  des  produits  bglcielsassocies  dees  composants: 

•  Standardisation  des  methodeset  des  procedures  dedevebppement. 

En  se  basant  surdes  modeiisations  cl^iques  de  developpements  bgidels  (volume  de  travail  par  phase. ..)  restimation 
des  gains  dOs  e  la  reutlisation  des  produits  toilets  est  donnee  figure  4. 


Effort  de  developpement 


Ainsi,  en  resume,  la  methodoiogie  de  devetoppemeni  de  logiciel  wegre  les  regies  de  reutisablite  qui  permettent  une 
recuperation  optimale  des  cornposanls  et  produKs  logiciels,  ainsi  quY  est  schematise  figure  $. 


de  r4utiliMbllM 


MMiodt  da  conctption  ^ 
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FIGURE  5 


Par  alMurs,  I  aal  i  notar  qua  oana  approctw  mainoOologique  doU  ttra  suwortaa  par  daa  outila  adapida.  Mdgras  dare 
un  alelar  logicM  ■  volrpaiagraplva  S - 

MlnliiilMitondtwitMitwtfarrBuia: 

Las  aur-oodts  angandtds  par  una  atreur  tors  du  ddveloppeineni  tfun  bglcial  ddpandanL  d  rdvidanca,  du  moment  oO 
cetia  anaur  aat  dagnostiquda  at  isoMa. 

Ainsi,  an  paitant,  oomme  prdcddamment  au  §  4i!.l,  tfuna  moddlisation  dassiqua  dun  ddvaloppamant  logiciel,  on  est 
capabla  ddvaluar  las  sur-oodts  engandrds  par  una  erreur,  salon  qu'aUe  est  isoMa  plus  ou  moms  tardlvament.  Cad  est 
prdsantd  figure  5. 


•  sat  done  capital  dimrodults  lea  contramtes  da  devatoppamsm.  imposeas  par  las  actions  asposeas  dans  lea 
paragmpnaa  precedents  pour  mlnlmlaai  las  ilaquasdanauia.  dans  la  inediodoicgla  da  ddMeloppanient. 


QsssfMrijnjiMptllssajtsj^^ 

-  NecasaMdavaldarlesresullalsdachaquaphaaa. 

-  NecassMdavemiarlaooneianosdsspredulstcliaquapnass. 


I 
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-  N6c«sM  (flioler  Im  oompotaitt  kigicMi  (6  tous  In  mwaml  m  stindaidisanl  laura  IranMnf  -  Martten  n  i6gln 
davMHia- 

-  Edcler  dn  rtgin  ifullllsallan  da  rAMef-LdgleM  da  la  mMiodolagie  al  mattie  an  oauvra  lea  alnickim  da  proiet 
pafflMtanl  da  In  uMaar. 

ttellilMd«la<IMnilm<*iliviW.il ; 

U  (MIMIon  ^ 

■  Aspect  McMqMiacauvraM  In  pmMinnllda  am  caradddsliqunduiDglciel. 

-  Aspect  maRilaa  (Toauara  aytMma  qui  rSpetcula  su  la  bglclal  In  pniblCrnn.  ddciils  pidcAdeinnenl,  at 
dicoulanl  dn  oontiaMn  Ifiipaa^  a  ravionneur. 

Aapatd^hnjquaj 

Son  obtedii  eat  da  mallrisar  la  darinlion  du  bgidel  afin  d an  conltdier  In  oodls  el  ddlais  da  dCvatoppament. 

Cedjn£pn: 

-  lacupCration  da  raxpddenca  aoquisa  lore  dn  dOvaloppaniants  antOriaure  alln  da  lain  una  asllmalion  coirecle  das 
oodls. 

-  pfdparallon  (fun  modOla  liaua  du  ddvaloppafflent,  adapi6  aux  paitlculafil6s  da  cliaqua  application,  ath  da  pouvoir 
umre  avac  p<6dslon,  rOvolutbn  das  coOts  rOals  pat  lappod  am  estimations  InlPaln  an  tonclion  dn  phaisn  du 
dOveloppenianl. 

/tfG*^*A|K!»dOama.iysMnw  ^ 

Comma  on  fa  vu  pidoOdemmenI,  J  3.2..  ravbnneur.  MaRre-ifOeuvia  systdme  dot.  pour  ripondre  am  contraimn 
nouvain  quI  U  son!  apparues 

■  prendre  an  charge  la  responsabaUduddvsIoppemantdnIogiclels. 

-  partlciperaced6valoppe(nent(vojr§S.3). 

-  mailrlserlagastlondeoonfiguratbndeslogiciels. 

Cn  aspects  da  la  mailrise  da  la  dornltbn  du  bgbbi  sons  piis  an  conple  par  rmifoductbn.  dans  rAteHar-(.ogbbl.  (foutils 
sp6cfiquas(volrS5.2). 

S.  nEVELOPPEMEHT  DF  1 QCICI6L  PAB  IE  MATniM  OEUVBE 
S.1.  MWiodtHDQla  Adroanatlala  •  DMsIon  Hdllciiiittfti  ; 

La  nbthodobgb  suMa  par  fAdrospatlab  -  OH  dans  sn  dOyaloppaments  da  bglciais  enbarquds  repose  sur  trois  points  qua  ton 
(MfMra.  un  peu  plus  an  ddlall  d-aprn : 

•  Uncycbdeddvebppemenl. 

-  OnacUvItdasclairemanidMninpourchaquaphasa. 

-  Una  mdthoda  da  ddvabppamenl.  nagnoupant  la  phlbsophia  da  travail  alnsi  qua  bs  rtgtes  (futlNsatbn  das  outils  da  rAteHar- 
Logidel  qui  an  ddooulenl. 

5.1.1.  Cvda  da  ddvelcixieniant . 

la  cycb  da  ddvabppamanl  bgbbi  ullbd  suit  bs  axlgencn  Slabis  par  bs  nornin  el  slandaids  an  vigueur  at  pbs 
partbuWremenl  ta  MIL  -  STD  -  2167A. 

Ca  cycb  eslschdmaiisd  figure  7. 
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5.1.2.  AalKMgdwehaMM- 

On  ne  dom  id  qulira  dMcriptlon  brtve.  dMntaani  uniquMngrt  I*  type  da  Iravaux  r^alste. 

aggmiPlfciiiig.: 

L'analyat  da  la  apdcMnilon  d'axtgancaa  logicitllat,  tounda  par  raquipa  ctnugaa  da  FMude  du  tystame.  as)  tana  par  lea 
apdclaWaa  logi^  da  tapon  a  anprimar  oaa  apdctteallona  ayiMiiia  dun  poM  da  vua  loglMI,  al  pour  i^oular  laa 
axIgancaalDgMalaaapacllquaa. 

ConoagtonpnHMn^^ 

Cadasllapnrniarrilvaaudalaphaaadaooneapdanglobala.  IconduHaiadaiMiondesionrdionlogiciallas-auCSC-da 
rappUcadoa  Au  tarma  da  eada  dlapa,  laa  apaeBeadona  axiamas  da  ctiaqua  toncUon  logiclalla  son  produltas,  da  lagon  a 
MnaMrar  laa  acdvaas  vara  raiapa  aulvarae. 

Laa  rdaulats  da  cads  phase  son  protolypaa,  da  (agon  a  valdar  leur  coharanca  sans  las  aspects  lamps  rSel  at  inartacas 
enrafoncdone. 


Corroagdon^lnanalra  afljnte : 

Carta  aiapa  paut  am  oonskiaraa  comma  la  ooncapdon  praimfeiaira  da  chaqua  lonctlon  logicMa.  basae  sur  las 
spaddeadona  astamas  laauas  da  ratapa  pracadame.  Cad  oondud  a  la  spacdlcidlen  externa  das  modules  dailnissant 
unatoncdonloglcMs. 

ChaipieloncticnsalprBlclypaa,apardrdasrasidal8dacallaaiapa,poursnvaldarleurcohaianca. 

EvMammsnl.  la  nombrs  da  nivaaux  da  radinemsnl  paut  airs  ddiaren  (funa  appacadon  a  una  autre,  an  loncdon  du 
rpieau  da  cildcia  da  rapplcstion. 

Conup^daiaam: 

Chaqua  module  logicial  asl  analysa  an  data*,  sans  raspact  programmatlon,  a  partir  da  sas  spaddcadons  axtamas.  Cad 
toumi  done  urw  spadlicallon  rfanalysa  dataads  da  cheque  module,  angloban  la  ddlinaion  das  unUds  da 
prograrixnaiion  -  ou  CSU - 

Co^: 

Lon  da  oella  phase  la  coda  source  das  unMsast  acrt  etcoiTipM,apaillrdesspacincationsd'analysedaiallias. 


Tests  unilairas : 


Chaqua  unSd  (CSU)  est  testda  Indapendammen,  dapras  las  spadficatlDns  da  tests  unSairas  Indusas  dans  la 
apaclicadon  (farialysa  dataiae  du  modula. 

Las  modules  bglciels,  tormant  una  fonction  logideae.  son  MagrSs  el  la  londlon  testae  rfapras  las  spacWcations  da 
tests  acritas  Iota  da  la  conception  praiimlnaiis  (dsuxtama  phase) . 

On  aura  done  aulan  da  niveaux  crmagration  qua  da  ntireaux  da  conception  praiiminaiia 

inagrMjonalt^c^loi^M : 

Las  londlons  logiclellas,  constituani  la  logidel  rrappllcation  dim  Squlpaman  (CSCI),  son  inagraes  el  ca  logidel  asl 
atom  testa  an  regard  da  sas  spacif  cations  da  test  acraes  tors  da  la  conception  prdliminaiia  (premtare  phase) 


5.1.3. 


La  mathoda  appiquae  lors  dun  daveloppemen  da  CgCiel  est  basae  sur  rexpartance  acquisa  Ion  da  pracadens 
davaloppamanla.Enoansaquenca.ondonned-dassouslasbasasdalamaitiodaapplquaa  parrAarospatlala-DH : 

-  Oaux  points  da  vua  ditarsnts  dolven  atre  adopias  pour  las  deux  phases  da  conception  ■  praNminalrB  at  dataSiaa  da 
tagona: 

.  Introdulre  loules  las  lonctionnaMas  du  logiclel  ainsi  qua  leun  Iner  relations  (Ter.ps  rael  at  Intertaca)  lors  da  la 
conception  prailmlnairs : 

Cad  constllua  Is  pom  da  vua  Tondlonnar  qui  dot  am  adopta  pour  la  concapticn  praimninaln. 

.  Sapererlesaxlgancaslogicielesdasconrainesderancalion: 

Cast  done  la  pom  da  vua 'raaKsanon' qui  do*  am  adopia  pour  la  ooncapllo.  I  dataMa. 

-  Lea  activias  da  chaqua  phase  dun  davsioppsman  dolven  am  strictemen  rampias,  las  rasullats  rfuna  aclivita  son 
nacessamspaurexaculsroonecIsmenraclivMsulvaiae: 

-  Da  tagon  a  minlmisar  las  ansun  at  las  moOMcations  au  ooun  (Tun  daveloppemen'.  el  a  assurer  Is  pars  haul  niveau  da 
aabwa  pour  la  logicial,  las  rasuMs  das  acdvaas  dolven  am  vsldas  avan  quia  soiani  uMMa  pour  la  phase  aulvane. 

UWOBOn  OtlinitinOM. 

La  description  da  la  mathoda  eat  donnaacN)asaous(llguie  8). 


PHASE 

METHOOE 

COHMENTAMES 

Concapllon  pteamtnalia 

MQOMMHm  OBBCVinniP  ■■  IMn^ 

cliliii  <iM  tooteWa  MMgianl  Im 

HodeiiaaEon  du  loglelal  an  mm- 
dulaani  aknutanemaM  laa  aapacta 
tantpasM  at  foncUonnals,  au 
tmvara  iTun  praceaaua  da  rallna- 
niant  daaoandanL 

Ptototypaga 

AnA  -a--*.  mi  liiia  a 

■nfiwinnvDon  m/a  qw  moiNm 
du  logicM  IMC  vMllcAion  di 
coMmacc. 

VaOdaUon  daa  modilaa  du  loglelal 
an  axeculaM,  aur  camiWaur  hdla, 
catta  Impieniaiilallon  ADA. 

Conception  detaiiea 

Utilaallan  du  langaga  da  haul 
nhraau  conuna  langaga  da  con- 
caption. 

Convaralon  du  modila  da  concep¬ 
tion  an  un  modila  da  lealsrtlon. 

Oodaga 

Traduction  du  modMo  do  iMtoUon 
•n  tnatruetloftt  du  langaoo  do  hout 
nivoou. 

RtBnomont  du  modtn  do  rOoltoo^ 
non. 

fKHJREB 


Outjte95£oitsAce!t^i^!ndojqg^ 

II  esi  Mdeni  <fja  dM  autns  son  n^cessaires  pour  siyvorter  la  tntthode  du  dtvsloppenien  (Mate  (Messous. 
Cesoujtsdpk^donMa^lS,^  exIgeno^i^anM  i 

-  Las  onis  devan  suppoitordes  pains  da  vuedWOtensdolven  Mrs  dSIPraiSs. 

OoiK  las  outils  suppoitan  la  concepUon  pr^llmlnalra  seron  dnarans  das  ouWs  si^ioitan  la  concapllon  iMIalMa. 

-  ADA  ast  la  langage  da  haul  niveau  ralsraj  par  lAdiDEpaiiale-DH. 

Las  outts  uMsOs  dans  FAialer-Logiciel  Aerospatiale  -  DH  son  dtcrts  dans  la  paiagmilw  suivart. 


U.  Atailaf-Loolclal  Aeromatlala  •  DH  : 

OndeciKlci.brievsnien.lasoulllsinisenplacaatimegresdansunaiaier  loglciel,  par  Aen»paliala-DH  pour  stpporlarsa 
mWiodalogie  da  devaloppernen  da  ioglci^  atnarcaiea. 

EaQBfSHJpaiFlfilU.: 

L'ouHEPOS-RaslutisepaurdecitraiesaxiganoaslogicielesanlnrDduldaiildanslalaiaedasniolsciespouvanetiBrapris  at 
tastes  tors  da  la  oonoapdon  presmlnaira. 

Conoag^^reinilrata: 

EPOS-Rsuppoita  las  deux  etapas  da  la  conception  preimlrialiesalonuneappiocttatiietatctilaeadBSDandanla. 

Grice  e  cat  ouM.  la  togidal  esi  structure  sanulaneinen  sous  las  deux  aspects :  1011010111101  at  dynanilqua. 


Las  ntodilas  issus  das  phases  da  conception  prilminaire  sort  traduis  an  ADA.  cornpMa  at  executes  pcur  valdsr  raichitectuie 
toQicieis. 

CoraeetiondOO|te: 

L’analysa  detaMa  das  modules,  issus  da  la  conception  preMnaie,  est  tale  i  raide  du  langaga  ADA,  uHse  oomne  un  iangage  da 
conception. 

routes  las  etapas  da  cotta  conception  detaiea  son  coirpaeas  at  done  vaHdeas. 

Las  nouvaaux  devstopparnsnts  da  togUets  anbantues  i  Aenapaeala  -  DH  son  M  avoc  ADA  oonsns  langaga  dlnpieinantaSan. 
Juaqu'i  presort  dautras  langagas  on  iM  utasis.  dans  la  cadre  da  cat  aMar  logiGM  (Pascal  LTR  V2,  C.  FORTRAN,. . .). 

Gaatlondecontiguratlon : 

U  gestlan  da  oonAgutMon  ds  ptoduedon  (aoucaa.  Oilats... .)  aat  Wto  i  raUa  da  icuti  PALAS4. 

Actueisinsn.ligaaaondaoaniguratlonconpIMa-Stnjclurad’AccuHgeianiouBlesotlalsaasccMaiunbgIcM.aatlala 
egatarnan  par  PALAS4.  Capan^  in  as,  catts  Stnictuia  dAooual  Sara  tala  t  raua  d\in  outi  speoiqua  conatnil  aulour  (funa 
base  da  dorstea  rslatiannaas  ORACLE. 
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OuHiooinglinMniiras : 

Ugetfond*rnpM8nc«<niiMiMd(logicMMfatatlWd*tfUn()ull,<Mvgt)P|i«parAtoS|iatiato-OH,appaWOML, 

p«tiimitd>)«lrele»««(liwtlBned»coai»tfun<ltvtlcpp«iTieH»nloni!ilond»: 

-  nnllMno*d((iiMaUi«(cainpleiiM,t|ip*tfa|]|!leation,...), 

-  lMemctMilli|iMMlMi<«iialtn*no)M(Maftfuintetondasittnlopi)wii0i«sanlMaun. 

UauMdn|M(MloaitMM*in.M*(MI*d*Eros-P.ipM1lrdM(«i>nn4Mln«aln(roML-AdiaqMpliaMdu 
dtv*lD|ip«niM(,  IM  dMMlM  OML  (M  finaae  t  ieur  Mifanaion  dw  rtaukatt,  pfcMtim  lamorMs,. . 

L'al«l»floglclelA<iDip«ll«l»-OH«d«c>i«iiii<l«<<*d«wou8(llBuf»9). 


&3.  n.i«inn.  /  Sni.«.OiimMctimi 

ComiTMla  MtdiprtoManinienl,ran)acatlondeoette>tntagle*ntnaWred»loslcjels,nfcess«e la miwefl place dentaUons, 
enM  ravkinneur  MaKra-dOauvre  at  see  sous-oonlnctanta,  aitapMes  a  cane  sliialion. 


CastalalloneertfarAaiospallala-DH  at  sea  aoua-conifactania  sett  otateadana  la  tableau  ctdasaoualHguia  10). 


RESPONSABIUTE 

DESLOQICCLS 

DEVELOPPEMENT 

DESLOGIOELS 

DEFMmONOES 
PROCEDURES  DE 
DEVELOPPEMENT 

tMvttafpanwni 

tfippicMont 

A<ieaiMilala-DH 

A4refp«W*-DH 

A«fOR9Mitlt-DH 

CMculMMmdt 

QMlIOfl  tytUlM 

MroipiM-DH 

Oonoipilon 

AtfnMpMlilt 

DH 

AanopadaM-DH 

FoncUm  y/' 

y/'  Non 

Mmpi. 

DH 

Soot- 
y/^  oontfte. 

EqutMmaMi 

Soudcaniiactanl 

Ooui  coxiiriim 

(ttlon  tfit  tidQtnctt 
AifOipMIt-DH). 

RQUREIO 


t 


i 

r 


i 

t 


f 


7-10 


L'wichalnainM  das  acdiiM*  priaa*  an  ootnpla  par  la  Matoa-tfOauvre  an  toncdDn  daa  phasea  du  dtvaloppamait  oompM  eat 
dtenilgunll. 


FIGURE  11 


«.  CONCLUSIONS: 


La  amagia  qji  a  M  dtola  cldaaaua  oat  aulounnui  appiquae  dana  las  pngramnaa  davionique  an  coura,  a  la  Division  Haioopiares  da 
rAaioapadale.  L'ansamlila  das  moysns  el  das  atnicturss  nacsssaires  a  son  kipad,  dans  Is  cadre  das  grands  progrananas  nouveaux  eat 
an  placa.  Las  avokitkins  futures  auranl  pour  bul  da  malnlanlr  laur  adaquatlon  aux  tins  rachaicMaa  sl  principalemeni  !a  maltilsa  das  oodts 
aldsadaiala. 
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COtiVERSIOli  TO  ]U)A:  DOBS  IT  BBALLT  HAKE  SENSE? 

Robert  A*  Converse 
Hitchell  J*  Bessman 

Computer  Sciences  Corporation 
6565  Arlington  Boulevard 
Palls  Church,  Virginia  22046  USA 


SUMMARY 

Change  is  an  integral  part  of  any  useful  operational  system.  Changes  are  required 
for  any  number  of  reasons,  ranging  from  minor  errors  that  exist  in  the  system  to  major 
system  upgrades  to  meet  totally  new  and  different  requirements. 

For  the  U.  S.  Department  of  Defense  (DoD) ,  the  manner  in  which  systems  are  changed 
is  of  significant  interest.  Major  system  upgrades  occur  in  virtually  every  system  at 
various  times  during  their  operational  lifetime.  One  way  to  manage  the  changes  and  to 
reduce  the  long  term  costs  associated  with  them  is  the  use  of  the  Ada  programming 
language  [1]. 

Avionics  is  an  application  area  within  DoD  for  which  the  use  of  Ada  is  a  serious 
consideration.  However,  in  addition  to  reducing  the  long  term  costs,  the  avionics 
software  must  also  meet  stringent  real-time  performance  and  resource  utilization 
requirements. 

This  paper  addresses  some  of  the  issues  associated  with  the  use  of  Ada  to  accomplish 
system  changes.  Background  and  general  issues  will  be  discussed  as  well  as  some  concerns 
that  are  specific  to  avionics  systems. 


INTRODOCTION 

Ada  was  developed  by  the  OoD  to  provide  a  standard  language  for  the  development  and 
maintenance  of  mission-critical  systems.  Initially  standardized  by  DoD  in  late  1980,  Ada 
has  been  steadily  maturing  both  as  a  language  for  large  system  development  and  as  the 
basis  for  a  comprehensive  set  of  tools  that  support  large  system  development  and 
maintenance.  Ada  is  ready.  Production  quality  Ada  compilers  are  available  for  most 
major  computers  available  on  the  market  today.  The  processors  supported  range  from 
microprocessors  such  as  the  Intel  80x86  and  Motorola  M680x0  families  through  minicom¬ 
puters  such  as  the  DEC  VAX  family  to  the  very  large  mainframes  such  as  those  produced 
by  IBM,  UNISYS,  and  CDC.  Software  engineering  tools  that  support  software  development 
methods  designed  to  take  advantage  of  the  advanced  features  of  the  Ada  language  are 
readily  available. 

Ada  is  mature  and  ready.  Why  should  it  be  considered  as  a  potential  language  for 
the  upgrade  of  a  system?  For  the  DoD  community,  there  are  two  reasons:  DoD  policy  and 
technical  advantages . 

From  a  policy  standpoint,  Ada  was  developed  by  the  DoD  to  solve  the  problem  of  the 
lack  of  commonality  among  major  DoD  systems.  Implementation  in  a  common  language  would 
provide  a  basis  for  reusability  and  transportability  of  software  components  among  systems 
throughout  the  DoD  community.  This  capability  would  lead  to  reduced  costs  for  system 
development  and  system  maintenance  as  well  as  increased  availability  of  people  who  know 
the  language,  tools,  and  methods  used  to  develop  those  systems.  With  this  goal  in  mind 
and  with  a  mature  language  at  its  disposal,  DoD  has  issued  policy  statements  requiring 
the  use  of  Ada  for  all  new  starts  and  for  all  major  system  upgrades  for  mission-critical 
systems.  Further,  the  use  of  Ada  for  non-mission-critical  systems  is  strongly  encouraged 
12,31. 


Ada  is  mature,  ready,  and  is  required.  Why  is  Ada  "better"  than  other  languages 
such  as  FORTRAN  and  COBOL?  What  is  the  technical  advantage  to  be  gained  by  using  Ada? 
Ada,  while  still  a  third  generation  (procedural)  language,  was  designed  to  support 
design  and  development  at  a  higher  level  of  abstraction  than  other  procedural  languages. 
However,  no  single  feature  distinguishes  Ada  from  other  third  generation  languages. 
Rather,  the  discriminating  factor  is  its  collection  of  features  in  a  single  language. 
Ada's  key  features  are  strong  typing,  abstraction  mechanisms,  packages,  tasks,  generics, 
and  exceptions.  Ada's  type  constructs  and  abstraction  mechanisms  require  that  interfaces 
between  software  components  be  clearly  and  completely  specified  and  that  the  compiler 
(and  run-time  system)  enforces  those  specifications.  Ada  facilitates  the  partitioning 
of  a  large  c<Miplex  system  into  a  number  of  smaller  and  more  manageable  components  through 
the  use  of  the  package  and  task  constructs.  Generic  units  permit  the  construction  of  a 
template  for  an  algorithm  that  can  be  used  with  the  types  and  abstractions  previously 
defined,  thereby  making  it  unnecessary  to  write  a  different  program  for  each  type. 
Exceptions  permit  the  developer  to  create  specific  error  handlers  for  unanticipated 
problMBS.  Features  such  as  these  allow  programs  written  in  Ada  to  be  designed  for 
change;  the  changes  can  be  isolated,  and  the  impact  of  a  change  can  be  easily  determined. 
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OPGRADB  DISCUSSION 

Planning  foe  a  major  system  upgrade  requires  considering  several  factors.  The  more 
important  factors  include: 

o  the  expected  operational  lifetime  of  the  system 

o  the  degree  of  modularity  within  the  system 

o  the  level  of  integration  associated  with  the  upgrade 

o  the  performance  and  resources. 

Operational  Lifetime  Factor 

The  expected  operational  lifetime  of  a  system  directly  impacts  the  expected  return 
on  investment  associated  with  the  cost  of  a  change.  If  additional  major  system  upgrades 
are  expected  for  the  system,  then  planning  for  subsequent  change  during  an  upgrade  makes 
sense.  However,  if  no  additional  upgrades  are  anticipated,  e.g.,  a  replacement  system  is 
already  in  development,  the  cost  for  the  upgrade  should  be  minimized.  Ada  is  designed  to 
provide  significantly  lower  costs  during  a  system's  operational  lifetime.  It  provides  a 
mechanism  for  incorporating  change,  reducing  the  costs  of  a  controlled  evolution  of  the 
system  in  subsequent  upgrades. 

Modularity  Factor 

The  modularity  factor,  the  degree  to  which  the  upgrade  affects  the  entire  system, 
affects  the  selection  of  the  approach  to  the  upgrade.  For  an  upgrade  to  a  tightly 
coupled  system,  the  upgrade  may  require  significant  modifications  to  the  existing 
software  within  the  system  as  well  as  the  development  of  new  or  additional  software  to 
meet  new  operational  requirements. 

Integration  Factor 

The  integration  factor  considers  the  extent  to  which  the  capabilities  to  be  provided 
by  the  upgrade  are  separate  from  the  existing  system  capabilities.  For  a  totally  upward 
compatible  upgrade  to  a  system,  the  interface  between  the  existing  system  and  the  new 
functionality  may  be  sufficiently  well-defined  to  allow  the  upgrade  to  be  developed  with 
no  impact  on  the  existing  system. 

Performance  and  Resources  Factors 

The  performance  factor  considers  the  amount  of  processing  to  be  accomplished  to  meet 
the  required  functionality  of  the  system.  A  major  part  of  this  factor  is  the  extent  of 
real-time  response  necessary.  The  resource  factor  considers  the  physical  limitations 
that  may  be  imposed  on  the  system.  An  example  of  such  a  limitation  is  the  amount  of 
memory  available  for  a  program. 

Accomplishing  an  upgrade  requires  considering  two  alternatives: 

(1)  use  of  some  language  other  than  Ada  or 

(2)  transition  to  the  use  of  Ada. 

Each  of  these  is  discussed  below. 


Non-Ada  Alternative 

A  decision  to  use  some  language  other  than  Ada  for  a  system  upgrade  is  based  on  the 
factors  described  above  as  well  as  the  applicable  policy  statements.  For  a  system  with 
a  short  operational  lifetime,  it  may  be  cost-effective  to  implement  the  upgrade  in  the 
language  in  which  the  system  was  originally  developed.  Of  course  such  a  decision  assumes 
that  the  target  computer  has  sufficient  capacity  to  accommodate  the  upgraded  system,  if 
the  current  target  computer  lacks  that  capacity  and  a  new  environment  must  be  acquired, 
then  concurrent  transition  to  the  Ada  language  may  be  the  proper  choice. 

Ada  Alternative 

Implementing  a  major  system  upgrade  in  Ada  can  be  accomplished  by  three  general 
approaches: 

(1)  redesigning  and  reimplementing  the  entire  system  in  Ada, 

(2)  implementing  the  upgrade  in  Ada  and  interfacing  the  upgrade  to  the  existing 
system,  or 

(3)  converting  the  existing  software  to  Ada  while  incorporating  changes  that  are 
designed  for  Ada, 
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Redesign  and  Ryiapl— nt  in  Ada>  This  approach/  while  providing  the  most  power  and 
flesibllityr  also  involves  the  highest  initial  cost.  However /  it  nay  actually  provide 
significantly  lower  life-cycle  costs  Cor  those  systems  that  have  a  long  operational 
lifetime. 

An  example  of  a  system  for  which  this  is  a  good  solution  is  the  D.S.  Navy*s 
Submarine  Satellite  Information  Exchange  System  II  (SSIXS  II}  upgrade  for  the  shore^based 
portion  of  the  system.  The  existing  systM  is  implemented  in  the  Ultra>16  assembly 
language  for  the  Navy  standard  AN/uyK-20  computer.  The  system  uses  all  of  the  computing 
power  and  memory  available  in  the  AK/oyR-20/  leaving  no  additional  capability  for  the 
proposed  enhancements.  Therefore/  the  Navy  chose  to  change  the  target  computer  as  a  part 
of  the  major  system  upgrade. 

The  initial  major  system  upgrade  was  to  redesign  and  reimplement  the  existing  system 
in  Ada  for  execution  on  a  DEC  MicroVAX  II  computer  and  to  incorporate  a  few  engineering 
changes  in  the  initial  release.  However#  the  new  design  was  structured  to  facilitate  the 
incorporation  of  further  changes  on  an  upgrade  schedule  that  calls  for  three  additional 
releases. 

The  redesign  and  reimplement  approach  is  harder  than  doing  an  initial  design  in  Ada 
because  of  the  requirMient  to  emulate  the  existing  system  interfaces  to  the  user  and  to 
other  communications  systems.  However#  the  approach  is  cost-effective  in  cases  such  as 
SSIXS  II  (Shore)  because: 

o  the  syst^  has  a  long  operational  life  expectancy 

o  planning  for  additional  changes  is  included  in  the  design 

o  a  new  target  computer  was  defined  for  which  Ada  is  available. 

Interface  Ada  Upgrade  to  Existing  System.  Mixing  Ada  and  non-Ada  components  within 
a  system  is  particular!^ attractive  for  a  very  large  system.  This  approach  requires 
careful  consideration  of  the  modularity  and  integration  factors.  For  an  upgrade  to  a 
system  that  is  not  modular#  mixing  Ada  and  non-Ada  may  be  impossible;  the  existing  system 
may  require  too  many  changes  to  permit  only  the  changes  to  be  in  Ada.  In  that  case# 
either  the  redesign  and  reimplement  approach  or  the  use  of  the  non-Ada  alternative  should 
be  considered.  For  an  upgrade  for  which  the  existing  system  will  be  enhanced  with  the 
addition  of  new  components  for  which  a  well-defined  interface  exists#  the  use  of  Ada  for 
the  enhancements  may  be  possible. 

Selecting  this  approach  depends  significantly  on  the  run-time  environment  for 
the  operational  system.  Ada  requires  specific  run-time  support  for  data  management# 
exception  handling#  and  task  management.  Thus#  the  target  system#  including  both  the 
computer  itself  and  the  operating  system  on  which  the  operational  system  will  execute# 
must  be  supported  by  an  Ada  compiler. 

This  issue  can  be  illustrated  with  two  examples.  The  U.S.  Army  is  updating  a 
management  information  system  to  produce  a  Standard  Financial  System  (STANFIN5).  This 
system  is  composed  of  five  major  components#  four  of  which  have  been  implemented  in 
COBOL.  The  fifth  component,  the  General  Accounting  package#  is  being  implemented  in 
Ada.  The  target  computers  are  commercially  available  computers  and  operating  systems 
such  as  the  IBM  30xx  products.  Both  COBOL  and  Ada  compilers  are  available  for  those 
systems.  The  interfaces  between  the  General  Accounting  package  and  the  other  STANFINS 
components  are  well-defined#  and  the  commercially  available  operating  systems  support 
communications  between  programs  written  in  Ada  and  those  written  in  COBOL. 

On  the  other  hand,  the  U.S.  Navy  performed  a  series  of  analyses  in  the  mid-1980'8  on 
the  transition  of  three  existing  mission-critical  systems  to  Ada:  the  TRIDENT  submarine 
combat  system#  the  AEGIS  system#  and  the  Restructured  Naval  Tactical  Data  System  (RNTDS). 
Each  of  these  has  a  different  run-time  executive  system  even  though  they  all  use  (or  will 
use)  the  Navy  standard  AN/UYK-43  computer.  To  provide  a  standard  run-time  system  for 
Ada  programs  developed  for  the  AN/UYK-43#  the  Navy  is  developing  an  Ada  compiler  and  a 
corresponding  run-time  system.  However,  because  of  differences  between  the  existing 
run-time  systems  and  the  one  being  developed  for  Ada#  to  transition  these  three  systems 
to  the  use  of  that  compiler  and  run-time  system  would  require  a  redesign  and  reimple¬ 
mentation.  Another  approach  would  be  to  provide  an  Ada  capability  for  each  of  the 
existing  run-time  systems.  This  approach  would  allow  mixing  (new)  Ada  programs  with 
existing  CMS-2  programs. 

Convert  to  Ma  and  Enhance.  A  third  approach  for  implementing  a  major  system  upgrade 
in  Ada  is  first  to  convert  the  existing  system  to  Ada  and  then  tc  use  Ada  directly  to 
implement  enhancements.  This  approach  is  usually  not  the  best  alternative  unless  (I)  the 
existing  system  is  large  and  well-structured#  (2)  the  enhancements  can  be  phased  in 
gradually#  and  (3)  a  reliable  automatic  conversion  tool  exists  to  support  the  translation 
from  the  old  implonentation  language  to  Ada. 

This  approach  may  be  the  fastest  way  to  produce  an  operational  Ada  language  version 
of  an  existing  system  with  some  of  the  advantages  inherent  in  the  use  of  an  Ada  compiler. 
Since  even  the  best  automatic  conversion  tools  will  produce  code  using  Ada  syntax  in  the 
style  of  the  original  language#  the  primary  short-term  benefit  will  be  the  use  of  the  Ada 
program  library  feature  to  guarantee  consistency  among  separately  compiled  units. 
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Additional  bonofita,  derivad  frooi  tha  use  o£  Ada's  package  construct  and  user* 
defined  types,  will  cone  during  the  enhancement  period.  After  the  existing  system  has 
been  translated  to  Ada,  enhancements  can  be  implemented  either  by  modifying  old 
components  or  by  adding  new  ones.  Mew  components  will  be  designed  and  implemented  to 
take  advantage  of  modern  Ada  language  features;  improvoients  to  old  components  can  be 
phased  in  gradually  without  affecting  the  operational  system. 

Never  recosmiended  is  a  strict  manual  translation  from  the  existing  source  language 
to  Ada.  It  is  expensive,  time*consuming,  and  prone  to  error.  Unless  an  automatic 
conversion  aid  is  available,  mixing  new  Ada  code  with  the  old  code  in  the  original 
language  may  be  a  better  alternative.  Unless  most  of  the  old  code  can  be  reused  with 
little  or  no  modification,  the  first  alternative,  of  redesigning  the  entire  system  to 
support  the  upgrades  while  taking  advantage  of  the  features  of  the  Ada  language,  is  the 
recramended  approach  [4]. 

Avionics  Issues 

Typical  avionics  applications  take  place  in  an  environment  in  which  weight,  power, 
and  volume  for  the  processor  are  at  a  premium.  Further,  avionics  syst^s  tend  to  require 
high  speed  processing  for  decision  making  and  control  purposes  in  real  time  within  an 
integrated  environment.  Therefore,  operational  avionics  systems  have  normally  been  built 
around  special  purpose  run-time  executives  and  execute  in  special  purpose  processors. 

The  application  of  Ada  to  avionics  applications  has  come  under  particular  study  because 
of  these  characteristics.  The  generation  of  efficient  object  code,  the  minimization  of 
run-time  overhead  for  memory  management  and  context  switching,  and  the  cyclic  processing 
of  sensor  inputs  are  all  issues  of  significant  concern  to  the  avionics  system  developer. 

Specific  solutions  are  starting  to  appear  for  avionics  implementations  in  Ada,  and 
Ada  is  being  used  for  the  development  of  avionics  syst^s  tS,6,7].  For  example,  as 
reported  at  the  International  Workshop  on  Real-Time  Ada  Issues  in  May  1987,  Ada  was  used 
for  approximately  88%  of  an  Operational  Flight  Program  developed  and  flown  by  General 
Dynamics,  Fort  Worth  Division.  However,  this  program,  a  rewrite  of  a  Jovial  implementa¬ 
tion,  required  more  memory  and  took  slightly  longer  than  the  Jovial  implementation. 

Thus,  care  must  be  exercised  in  the  use  of  Ada  for  upgrading  avionics  systems.  Ada  can 
provide  much  in  terms  of  reliability,  adaptability,  and  reusability  but  it  cannot  be  at 
the  expense  of  performance. 

General  Issues 

Planning.  Mo  matter  which  alternative  is  selected,  a  successful  system  upgrade  requires 
careful  planning.  The  beat  approach  can  be  selected  only  after  a  detailed  analysis  of 
both  the  existing  system  and  the  needed  upgrade.  In  addition,  it  is  essential  to  plan 
for  the  transition  of  personnel  and  the  computing  environment. 

Personnel .  Two  options  immediately  come  to  mind  for  develo'  fng  a  transition  plan  for 
acquiring  Ada-literqte  personnel:  (1)  hire  all  new  personne.  with  existing  Ada  expertise 
or  (2)  retrain  current  personnel.  The  first  option  can  be  dismissed  quickly.  Unless 
there  is  no  current  staff  and  all  new  personnel  are  being  hired,  some  amount  of  staff 
retraining  will  be  required.  Further,  even  if  there  is  no  current  staff,  there  simply 
are  not  enough  available  software  engineers  and  managers  with  both  experience  and 
competence  in  the  use  of  Ada  to  staff  all  Ada  software  development  programs.  Retraining 
experienced  software  personnel  in  the  efficient  use  of  Ada  and  modern  software  engineering 
practices  is  often  easier  and  more  econ<»iic8l  than  hiring  new  personnel  with  some  "Ada 
training"  but  no  experience. 

Managers  should  be  trained  first,  since  a  successful  transition  to  Ada  requires 
management  support.  Management  support  comes  only  with  an  appreciation  for  the  potential 
long-term  benefits  to  be  derived  after  the  short-term  inconvenience  of  transition. 

Initial  programmer  training  should  include  an  overview  of  the  entire  language  In  the 
context  of  modern  software  engineering.  The  emphasis  should  be  on  the  high-level  language 
features  that  support  good  software  engineering.  After  the  progranaers  become  comfortable 
with  the  language  structure,  more  advanced  features  and  details,  such  as  the  interactions 
between  different  fixed  point  types,  can  be  learned  as  they  are  needed  on-the-job  or  in 
advanced  seminars.  Some  pecple  will  inevitably  be  more  effective  Ada  programmers  than 
others,  just  as  some  ace  more  effective  in  COBOL. 

Computing  Bnvironment.  Once  the  decision  to  use  Ada  has  been  made,  selection  of  the 
proper  developiMnt  elTvironment  and  software  support  tools  should  also  be  a  carefully 
reasoned  management  decision.  Often  the  decision  will  be  at  least  partially  driven  by 
the  existing  hardware  and  operating  system  environment  required  for  system  development  or 
operation. 

Much  has  been  written  about  Ada  tools  and  programming  support  environments.  Many 
mature  Ada  compilers  are  available  for  most  popular  computers  and  operating  systems. 

Every  month  many  new  products  are  being  released  for  integration  into  existing  environ¬ 
ments.  The  rash  of  product  announcements  at  the  combined  International  Ada  Conference 
and  Ada  Expo  during  December  1987  Indicates  the  level  of  activity  to  improve  the  way  in 
which  software  is  developed  in  Ada.  Each  vendor  will  be  quick  to  point  out  that  his 
product  is  the  best.  A  comparative  evaluation  of  many  of  the  rapidly  changing  products 
would  likely  be  out-of-date  before  this  article  is  printed. 
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Unsupported  productivity  claios  associated  with  the  use  of  Fourth  Generation 
Languages  (4GL8)  are  highly  suspect.  Although  some  4GLs  may  be  useful  as  prototyping 
tools  and  others  may  be  useful  as  partial  code  generation  support  for  providing  an 
interface  to  commercial  software  products,  greater  gains  in  productivity  can  be  expected 
today  from  carefully  designed  reuse  of  software  components.  Although  the  world  would 
welcome  an  automated  tool  that  supports  the  effective  use  of  Ada  throughout  the  entire 
software  development  life  cycle,  no  such  tool  is  available  today. 


CONCLOSIOM 

We  have  shown  that  transition  to  Ada  for  an  operational  system  is  a  reasonable 
alternative.  The  technology  to  support  Ada  approaches  exists,  and  the  long-term  benefits 
far  outweigh  the  initial  costs  associated  with  such  a  change.  The  conclusion  is 
inescapable:  Ada's  good--use  it. 
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DISCUSSION 


W.Mansel,  (}e 

You  have  mentioned  in  your  presentation  that  for  the  conversion  of  software  into  Ada  the  mixing  of  Ada  code  with 
other  programming  language  code  was  realized.  Can  you  explain  what  languages  have  been  considered  and  how  this  has 
been  realized,  since  to  my  knowledge  Ada  compilers  currently  only  allow  the  input  of  assembly  code  packages? 

Author's  Reply 

To  my  understanding,  there  has  been  no  direct  intermixing  of  Ada  code  and  non-Ada  code.  The  systems  to  which  I 
referred  interfoce  components  written  in  Ada  to  components  written  in  some  other  langi^age  through  the  underlying 
operating  system  or  through  a  data  base  access  scheme. 
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Shobitt 


The  introduction  of  digital  avionics,  i.e.  freely  prograimable  embedded  and 
distributed  real  time  computer  systems  into  military  fighter  aircraft  sind  the 
accompanying  transition  from  electromechanical  to  software-intensive  systems  are 
forcing  the  aviation  industry  into  new  approaches  to  systems  design, 
development,  integration  and  test.  Avionic  systems  development  and  software 
engineering  are  becoming  more  and  more  intertwined  desciplines  that  critically 
depend  on  each  other.  Software  is  no  longer  just  one  part  of  the  system  -  it  is 
the  system.  System  functions  and  system  performance  are  tightly  coupled  to  real 
time  mission  software.  Hence,  because  of  the  complexitiy  of  nowad^s  systems, 
software  changes  can  no  longer  be  considered  easy  and  quick  as  cranpared  to 
hardware  changes. 

The  purpose  of  this  paper  is  to  describe  the  avionic  systems  development  metho¬ 
dology  established  and  used  at  MBS,  its  relationship  to  software  development  and 
the  experiences  made  by  the  application  of  this  development  methodology  and  its 
related  tools  to  such  major  programs  as  the  development  of  the  Electronic  Combat 
Reconnaissance  Tornado,  the  integration  of  the  HARM  missile  into  the  Interdic¬ 
tion  Strike  Tornado  and  the  Improved  Combat  Efficiency  Program  of  the  German 
P-4F  Phantom. 

As  far  as  the  weapon  system  Tornado  is  concerned,  avionics  system  design, 
integration  and  test  as  well  as  system  software  development  are  trinational 
untertaklngs  which  include  three  different  customers  and  different  operational 
needs.  Any  systems  development  methodology  has  to  reflect  these  prerequisites. 
Therefore  this  paper  also  addresses  problems  and  solutions  for  International 
cooperation  in  systans  and  software  development  and  their  impact  upon  project 
management  and  control. 

The  toolset  in  use  for  system  development  requires  further  enhancements. 
Potential  inproveroents  of  existing  and  requirements  for  additional  tools  are 
also  being  described. 


1.  lotroducrtlon 


MBB  has  been  awarded  in  the  last  few  years  three  major  system  development 
contracts  for  military  aircraft: 

-  P-4P  Improved  Combat  Efficiency  Program 

-  HARM  missile  Integration  into  Tornado  IDS 

-  Electronic  Combat  Reconnaissance  Tornado  (BCR) 
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These  programs  are  characterised  by  a  considerable  increase  of  electronic 
systems  con^lexlty.  This  reflects  the  generally  recognised  trend  to  invest  more 
and  more  in  avionics  systems  in  military  aircraft  (percentage  of  avionics  to 
flyaway  costs  being  some  \0  %  a.  decade  ago,  nowadays  being  some  30  H  and  more 
for  future  weapon  systems).  The  congxiting  capacity  of  the  ECR  Tornado  increased 
considerably  compared  to  the  basic  Tornado  within  4  years:  the  number  of  on 
aircraft  loadable  conputers  from  1  to  6  and  their  memory  capacity  from 
128  kwords  to  nearly  3000  kwords.  3  of  the  6  computers  are  mission  computers  and 
were  prograomed  by  our  conpany.  Obviously  changes  of  this  size  can  otily  be 
realised  with  a  disciplined  methodology  for  system  and  software  development. 

There  were  also  typical  experiences  with  less  rigid  methods  of  the  past  that 
supported  this  view:  missed  schedules,  budget  overruns,  unrealistic  planning  and 
hence  loss  of  credibility.  In  the  long  run  this  affects  the  competitiveness 
of  a  conpany  in  an  intolerable  way. 

MBB  therfore  introduced  a  more  rigid  methodology  of  designing  complete  aircraft 
systems.  It  had  to  be  applicable  for  different  programs  without  major  changes, 
it  had  to  support  all  phases  of  system  development  and  it  had  to  assure  that  the 
interfaces  between  systems  engineering  groups  and  software  development  groups 
were  well  defined.  The  methodology  had  to  allow  for  iterations  in  specific 
idiases,  nevertheless  assuring  proper  completion  of  each  phase.  Finally,  as  many 
(biases  as  possible  had  to  be  supported  by  appropriate  tools  to  enhance 
productivity. 

The  methodology  adopted  is  closely  related  to  DoD  Std.  2167,  especially  in  the 
software  development  phases,  but  had  to  be  amended  for  some  of  the  other  phases. 
As  far  as  software  development  is  concerned,  these  modifications  reflect  the 
transition  fran  software  development  for  one  single,  centralised  computer  to 
that  for  distributed  real  time  on-boaird  computer  systems.  In  the  following, 
after  having  outlined  the  methodology,  emphasis  will  be  put  on  the  influence  of 
system  development  to  software  development  and  vice  versa. 


2.  Generic  Slystem  Developoent  Model 


In  order  to  be  independent  of  specific  projects,  a  generic  System  Development 
Model  has  been  developjed.  To  be  applicable  for  a  specific  project  it  had  to  be 
amended  by  Implementation  directions  specific  for  the  project.  For  the  purpose 
of  the  subject  of  this  paper,  however,  it  is  sufficient  to  deal  with  the  generic 
model  only. 

The  system  development  model  adopted  is  depicted  in  Fig. 1 .  The  main  features  are 

o  its  generic  set  of  steps  or  phases  according  to  DoD  Std.  2167 

o  the  definition  of  baselines,  i.e.  freeze  of  requirement  and  product 
standards  throughout  development 

o  the  functional  partitioning  of  the  operational  software  among  the 
distributed  computers 

0  the  strong  enphasls  on  a  disciplined  integrated  systems  development 
approach. 


Each  of  these  phases/  activities  will  result  in  products  (i.e.  documents, 
equipment,  software)  that  are  being  reviewed  at  the  end  of  the  specific  phase  of 
development.  Ideally,  the  next  phase  will  only  be  started  after  approval  of  the 
preceding  one. 
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Operational  Concepts 

The  Operational  Concepts  are  based  on  the  operational  needs  of  the  customer. 
They  will  be  defined  by  the  customer  in  close  contact  with  the  weapon  system 
company.  The  Operational  Concepts  either  define  a  completely  new  weapon  system 
or  just  inprovements  to  existing  systems.  They  form  the  basis  for  any  contract 
and  as  such  establish  the  (^rational  Baseline. 


^sten  Concepts 

This  phase  will  be  carried  out  in  the  following  steps: 
o  procedural  analysis  of  Operational  Concepts 

o  technical  analysis  of  Operational  Concep'^s  resulting  in  a  Preliminary 
System  Concept 

o  review  of  the  Preliminary  Systran  Concept 

In  the  first  step  the  Operational  Concepts  will  be  analysed  with  respect  to 
completeness,  feasibility,  consistency  and  impacts  on  related  further  tasks. 
After  having  clarified  inconsistencies  with  the  customer  the  Operational 
Concepts  will  be  technically  analysed  resulting  in  a  Preliminary  System  Concept 
accompanied  by  rough  estimates  for  required  efforts  and  tiTnescales.  A  formal 
System  Requirements  Review  (SHR)  will  be  held  with  the  customer  to  get  the 
System  Concept  being  agreed. 


System/Sufasystem  Requirements  Analysis 

The  Operational  Concepts  and  the  System  Concept  will  be  analysed  and  refined 
leading  to  the  System  Specification.  In  parallel  the  System  Test  Specification 
will  be  established.  These  documents  will  be  further  refined  to  the  Subsystem 
Specifications,  the  Interface  Control  Document  and  the  Subsystem  Test  Specifi¬ 
cations.  The  Slystem  Design  Review  (SDR)  finally  will  authorise  the  products  of 
this  phase  thus  constituting  the  ftaicticaal  Baseline.  In  addition,  development 
efforts  and  timescales  will  be  revised  and  refined. 


Bjuipment  Requirements  Analysis 

In  this  step  the  functional  baseline  as  established  above  will  be  used  to  derive 
the  impact  on  the  equipments  of  the  system,  i.e.  how  can  the  changes  required 
for  by  the  subsystem  specification  be  implemented  in  all  affected  equipments. 
This  will  include  the  definition  of  the  Equipment  Specifications,  the  definition 
of  the  Equipment  Test  Specifications,  the  refinement  of  the  ICD  and  will  include 
the  Equipment  Specification  Reviews. 

Together  with  the  results  of  the  Software  and  Test  Rig  Requirements  Analysis 
phase,  the  above  will  define  the  Allocated  Baseline.  At  This  point  in  time 
customer  induced  requirements  must  be  frozen  in  order  to  proceed  to  full  scale 
development  in  a  disciplined  and  controlled  manner. 


Test  Rig  Requirements  Analysis 

Test  benches  on  ground  consisting  of  stimulating  and  recording  facilities,  of 
real  aircraft  hardware  and  of  a  flexible  interconnection  wiring  we  call  a 
"test  rig". 
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In  general,  new  system/ subsystem  requirements  and  their  corresponding  test 
specifications  will  ask  for  enhanced  test  facilities  (rigs)  and  test  software. 
Therefore,  in  order  to  provide  those  in  time,  the  test  rig  requirements  will 
have  to  be  analysed  in  parallel  to  the  hardware  and  software  requirements, 
comprising  of  the  definition  of  the  Test  Rig  Requirements  Specification,  the 
definition  of  the  Test  Rig  Acceptance  Procedure  and  concluding  in  the  Test  Rig 
Requirements  Review.  In  addition  effort  and  timescales  will  have  to  be  defined 
in  this  step. 


system  Softiere  Requlrenents  Analysis 

"Systmn  software"  is  defined  herein  as  being  the  collection  of  all  software 
packages  in  all  freely  progranmable  on  board  conputers. 

Based  on  the  Subsystem  Specification,  the  ICD  and  the  relevant  Equipment 
Specifications,  the  necessary  enhancements  and  changes  to  the  System  ^ftware 
will  be  analysed.  This  will  be  followed  by  the  functional  partitioning  of  the 
different  software  functions  to  specific  computers.  This  phase  will  include  the 
definition  of  the  System  Software  Requirements  Specification,  the  definition  of 
the  System  Software  Test  Specification,  the  definition  of  the  (Software) 
Interface  Requirements  Specification  and  will  conclude  in  the  System  Software 
Requiranents  Review. 


Software  Requlrenents  Analysis 

Based  on  the  System  Software  Requirements  Specification,  the  ICD  and  the 
relevant  Equipment  Specifications,  the  requirements  for  the  software  of  each 
computer  will  be  completely  defined  and  the  impacts  on  all  relevant  Software 
Requirement  Specifications  for  all  relevant  processors  will  be  assessed.  Thus 
for  each  conputer  the  Software  Requirement  Specifications  and  the  Interface 
Requirements  Specifications  will  be  established  concluding  in  the  Software 
SpTCificatlon  Reviews  (Sai).  In  addition,  refinements  of  effort  and  timescales 
have  to  be  defined  in  this  step. 

Software  Requirements  Analysis  in  general  will  be  carried  out  in  parallel  to 
Equipment  Requirements  Analysis.  However,  in  case  of  an  embedded  computer  it 
might  be  necessary  to  define  the  equipment  first  in  order  to  be  able  to 
establish  the  Software  Requirements  Specification. 


Bpilpnoit  DevelopBHit 

Based  on  the  Equipment  Specifications  the  design  of  the  equipments  will  be 
defined  and  the  equipment  will  be  built  au:cordingly.  For  each  equipment  this 
phase  will  include  the  definition  of  the  Equipment  Top  Level  Design  Document  and 
the  definition  of  the  Equipment  Test  Plan  concluding  in  the  Preliminary  Design 
Review  (PER). 

After  PER  authorisation  the  Detailed  Design  Document,  the  Interfewe  Design 
Document  and  the  Equipment  Test  Description  will  be  defined  concluding  in  the 

Critical  Design  Review  (CER). 

Final  dR  agreement  will  authorise  equipment  production,  the  definition  of  the 
Equipment  Test  Procedure  and  finally  the  equipment  qualification. 


Test  Rig  Develc^nent 

In  parallel  to  hardware  and  software  development,  the  necessary  test  rig 
facilities  will  be  developed.  In  order  to  assure  a  full  match  with  those  two 
other  parallel  activities,  a  similar  approach  will  be  adopted.  It  will  start 
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with  the  definition  of  the  Test  Rig  Top  Level  Design  Document,  that  will  be 
assessed  by  the  Prellaiiiary  Design  Review  (FIK). 

After  HXi  authorisation  the  Test  Rig  Detailed  Design  Document  and  the  Test  Rig 
Interface  Design  Document  will  be  defined  concluded  by  the  Critical  Design 
Review  (CZR).  Pinal  CDR  authorisation  will  initiate  test  rig  production  or 
upgrade  and  test  rig  acceptance. 


Software  Develcgaent 

Software  development  will  cover  the  design,  iiiplementation  and  part  of 
integration/testing  of  the  software  product  reflecting  completely  the  specified 
requirements.  For  each  computer  the  preliminary  design  of  the  software  will  be 
defined  resulting  in  the  Software  Top  Level  Design  Document,  the  Software  Test 
Plan  and  leading  to  the  Preliminary  Design  Review  (HX). 

After  PDR  authorisation  the  detailed  design  of  the  software  will  be  established 
resulting  in  the  Software  Detailed  Design  Document,  the  Interface  Design 
Document,  the  Database  Design  Document  (if  applicable),  the  Software  Test 
Description  and  will  be  concluded  by  the  Critical  Design  Review  (CDR). 

Pinal  CDR  aurhorisatlon  will  initiate  coding  and  unit  testing  of  the  software 
resulting  In  the  Source  Llstlng(s)  and  Source/Object  Code,  followed  by  cc»nponent 
(CSC)  Integration/ testing  of  the  software. 

The  latter  will  result  In  Source/Object  Code  modifications  and  the  Software  Test 
Procedure  and  will  be  concluded  by  the  Test  Readiness  Review  (TRR). 


Bqulpmt  Testing 

According  to  the  Equipment  Test  Plan,  the  Equipment  Test  Description  and  the 
Equipment  Test  Proc^ure,  equipment  testing  will  start  with  engineering  tests 
and  lead  to  the  qualification  tests  in  order  to  obtain  the  preliminary  clearance 
for  flying. 

If  the  flight  test  results  show  pierforraance  to  the  specification  the  final 
Declaration  of  Design  and  Performance  (DDP)  will  be  established  and  authorised. 

Having  pjassed  all  these  steps  the  equipment  will  be  cleared  for  full  operational 
use.  In  case  of  embedded  computers  with  loadable  software  a  final  clearance  in 
general  can  only  be  given  after  hardware /software  integration  testing  which  will 
be  carried  out  during  system  integration/testing. 


Sof^nre  Testing 

Por  all  computers  in  the  systmn  this  step  of  testing  will  be  carried  out  indi- 
vidually,  testing  the  complete  software  product  (CSCI)  residing  in  one  indivi¬ 
dual  conqxiter.  Testing  will  be  concentrated  on  showing  that  the  inplemented 
software  satlfies  its  specified  functional /perforinance  requirements,  resulting 
in  the  Software  Product  Specification,  the  Version  Description  Document  and  the 
Software  Test  Repwrts. 


System  Softnore  Testing 

System  software  testing  will  be  performed  using  all  computers,  all  software  and 
all  interconnections  of  the  compiuting  system  to  assure  that  not  only  single 
coopiter  programs  but  also  the  system  software  as  a  whole  will  per  form  as 
specified. 
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£>iglneering  tests  and  then  qualification  tests  will  result  in  the  Version 
Description  Documents  and  the  System  Software  Test  Reports,  and  will  be 
concluded  by  the  fimcticnal  Ocafiffiratlon  Audit  /  Hiyslcal  Oanfiffiratiaa 
Audit  . 


Siystea  Integration  Testing 

System  integration/testing  will  cover  HW/SW  integration,  subsystem  and  system 
testing,  conprislng  the  definition  of  the  System  Test  Procedures,  engineering 
tests,  qualification  tests,  definition  of  the  System  Test  Notes  and  definition 
of  the  Plight  Release  Document. 

Only  after  completion  of  all  of  these  tasks,  the  next  ptose  "flight  testing" 
will  be  started. 


Fll^t  Testing 

The  main  goal  of  flight  testing  is  the  validation  of  system  performance  against 
the  System  Specification  in  the  real  environment.  It  comprises  the  definition  of 
test  flights,  the  test  flights  themselves  and  the  Flight  Test  Reports. 

A  R>rmBl  Qualification  Review  (KJR)  will  be  held  after  completion  of  the  flight 
tests  to  evaluate  the  test  results  and  release  the  system  for  operational 
service.  At  completion  of  the  review,  the  Product  Baseline  is  established. 


Operational  Service 

In  this  phase  the  final  product  of  development  -  as  defined  by  the  PraAtct 
Baseline  -  is  being  used  by  the  customer.  This  in  general  will  result  in 
maintenance  and  improvement  activities.  The  procedure  for  these  activities  is 
essentially  the  same  as  above  complemented  by  a  change  control  procedure.  This 
change  procedure  allows  to  Identify  the  phase  from  vdiere  onwards  changes  in  the 
documentation  /  products  are  required  and  to  record  these  changes  for  all 
affected  phases.  Thus,  in  general  not  the  complete  system  development  life  cycle 
will  be  run  through.  For  exanple  a  software  bug  might  just  affect  detailed 
design,  inplementation,  software  testing  and  system  integration  testing  on 
ground.  A  new  system  or  software  baseline  is  then  defined  as  the  old  baseline 
plus  a  controlled  collection  of  changes. 


3>  S^ystoBS  fiiglneerlng  and  Software  Develc^mi»it 


As  shown  in  Fig.  1,  we  have  established  two  handover  points  from  systems 
engineering  to  software  development  and  vice  versa: 

-  after  completion  of  the  Software  Specification  Review  (SSR)  the  Software 
Requir«Dent  Specifications  together  with  the  Pquipment  Specifications  form 
the  basts  of  software  design; 

-  after  completion  of  software  testing  the  software  is  delivered  to  systans 
engineering  for  system  integration  testing  together  with  all  equipment. 

In  large  avionics  projects  where  hundreds  of  development  engineers  are  involved 
the  organisational  structure  has  to  reflect  the  necessity  to  split  the  develop¬ 
ment  tasks  between  different  groups  and,  of  course,  between  the  weapon  system 
company  and  different  suppliers.  Especially  there  are  systems  engineering  groups 
and  separate  software  development  groups  besides  others.  Therefore  the  handovers 
are  not  just  transitions  from  one  phase  to  another,  in  addition  work  Is  trans¬ 
ferred  from  one  group  to  another.  The  technical  knowledge  and  background  of 
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these  two  groups  being  different,  much  care  has  to  be  taken  to  ensure  that  the 
transltiois  are  controlled  properly.  How  to  overcome  problems  resulting  from  the 
differmt  "languages"  the  systems  engineering  people  and  the  software  developers 
are  spewing  Is  described  In  the  following. 


3. 1  Bie  Software  Requirements  Analysis  to  Soflware  Design  Transition 

Vfliat  software  designers  would  like  to  get  before  starting  the  software 
development  are  Software  Requirement  Specifications  that  are  canplete, 
unambiguous,  understandable  and  written  in  a  formal  specification  language.  The 
specifications  should  not  change  at  all  throughout  software  development.  In 
reality  development  tends  to  be  different  from  this  ideal  case  for  a  number  of 
reasons. 

First  of  all  the  Software  Requirement  Specifications  have  to  be  updated  during 
software  development  because  e.g.  the  customer  introduces  late  requirements  or 
hardware  development  necessitates  changes.  Completeness  nay  also  be  difficult  to 
achieve  because  of  e.g.  a  not  yet  precisely  defined  hardware  interface.  The 
specifications  might  be  unambiguous  to  the  systems  engineer  but  not  to  the 
software  designer  because  of  his  different  background.  On  the  other  hand,  trying 
to  make  the  requirements  specification  too  formal  contradicts  the  way  of 
thinking  of  a  systems  engineer.  last  but  not  least,  even  if  the  Software 
Requirement  Specifications  would  be  ideal  there  might  be  a  need  for  changing 
them  when  implementing  the  software.  Consider  the  simple  case  that  the  software 
just  gets  too  big  to  fit  into  the  dedicated  computer  -  a  situation  not  unusual 
to  avionics  computers  because  memory  is  still  a  restriction  nowadays.  In  order 
not  to  change  the  hardware  one  might  decide  to  reduce  the  software  requirements. 

So,  what  did  we  do  to  improve  this  situation?  In  order  to  reduce  communication 
problems  the  senior  software  designers  were  involved  during  the  software 
requirements  analysis  phase.  In  fact,  they  wrote  part  of  the  software  require¬ 
ments  thanselves.  In  addition,  the  systems  engineers  participated  in  several 
design  audits  and  especially  in  the  Preliminary  Design  Review  (PDR)  and  the 
Critical  Design  Review  (CDR) .  Also  a  lot  of  day  to  day  coranunication  was  stimu¬ 
lated  between  the  two  groups. 

To  prevent  at  least  part  of  the  inplementation  problems  and  to  be  more  specific 
when  writing  software  requirement  specifications  we  decided  to  go  for  a  specific 
kind  of  prototyping  when  defining  the  subsystem  and  software  requirements.  For 
that  purpose  the  System  Prototyping  Rig  (SPR)  was  built  (see  Pig.  2).  It 
consists  of  a  number  of  graphic  workstations,  microconputers,  real  aircraft 
conputers  and  displays  as  well  as  a  fully  operable  cockpit.  The  different 
equipments  can  be  connected  in  a  very  flexible  way  via  a  connection  matrix  and 
via  different  busses  to  simulate  any  avionics  system  configuration  required.  The 
software  offers  an  aircraft  model,  several  sensor  simulations,  powerfull 
grai^ics  for  the  cockpit  displays,  a  software  development  environment  for  all 
computers  and  a  powerfull  test  environment. 

The  SPR  helps  in  verification  and  experimental  tests  of  new  system  architectures 
and  in  demonstrating  system  performance.  It  is  also  used  for  the  evaluation  of 
software  development  environments  for  target  cotputers  and  of  test  support 
software.  New  equipments  can  be  tested  in  a  eeu"ly  stage  in  a  realistic  system 
envirormient.  last  but  not  least  critical  software  modules  can  be  tested  and 
their  user  interface  can  be  checked  by  aircrews.  Prom  our  point  of  view,  system 
prototyping  is  an  essential  means  to  provide  a  sound  enpirical  database  for  full 
scale  development,  i.e.  when  the  system  development  is  covered  by  a  fixed  price 
contract. 

In  addition  to  a  complete  set  of  documentation  in  accordance  with  DoD  Std  2167 
it  proved  to  be  very  Inportant  to  have  tool  support  for  cross  referring  of 
software  requirements  to  design  documentation.  Only  then  useful  verification 
of  tl»  design  of  complex  avionics  systems  may  be  obtained. 


9-9 


SBA100 

MOTS 

Fig.  2  System  Prototyping  Rig 


There  are  other  measures  we  adopted  like  rigorous  configuration  control  or 
tool  support  wherever  possible.  They  are  nowadays  widely  used  and  we  there¬ 
fore  do  not  want  to  expand  on  them  here.  However,  it  might  be  interesting 
to  add  a  few  remarks  for  international  programs  like  Tornado  or  EFA.  Part 
of  the  work  is  carried  out  in  international,  centralised  teams;  the  other 
part  is  subdivided  into  workpackages  for  the  participating  companies.  In 
order  that  this  workshare  be  successful,  an  international  coordination  body 
has  to  be  established  and  the  interfaces  have  to  be  clearly  defined.  For  the 
transition  from  software  requirements  to  software  design  one  has  to  be 
even  more  careful.  A  centralised  international  engineering  team  has  to  collect 
all  the  software  requirements,  harmonise  them  and  define  the  baseline  for 
further  work.  Ckily  then  each  software  development  team  for  each  computer  is 
allowed  to  start  software  design.  Any  change  of  the  baseline  has  to  be  care¬ 
fully  controlled  by  the  centralised  team  and  incorporated  by  the  software 
development  team  after  authorisation  only. 


3.2  Ihe  Software  Testing  to  Sfsteo  Integration  Testing  Transition 

State  of  the  art  avionics  conpiting  systems  consist  of  a  number  of  anbedded 
conputers  linked  via  busses.  When  starting  system  integration  systems  engineers 
would  therefore  like  to  have  error-free,  fully  tested  software  for  each  computer 
delivered  all  for  integration  testing  at  one  point  in  time.  With  the  classic 
approach  -  test  the  software  for  each  computer  on  a  single  computer  test  bench, 
then  test  all  software  and  all  hardware  on  a  system  integration  test  bench 
(v^lch  we  call  "test  rig")  -  responsibilities  of  software  developpers  as  opposed 
to  sytems  engineers  are  clearly  separated,  but  system  integration  in  general 
detects  a  number  of  software  problems  caused  by  the  real  time  behaviour  of  the 
system  not  anticipated  in  software  testing. 


In  order  to  avoid  these  problems  as  far  as  possible  we  introduced  an  overlap  of 
pure  software  testing  and  pure  syst«B  integration  testing  called  system  softvare 
testing.  This  testing  {hase  is  carried  out  using  all  or  at  least  most  of  the 
avionics  computers  plus  some  additional  key  hardware  like  displays  to  perform  a 
real  time  system  software  test.  Both  software  developers  and  syst«ns  engineers 
participate  in  testing  to  be  able  to  separate  problems  caused  by  software  from 
the  ones  caused  by  hardware.  Thus  the  software  Is  finally  handed  over  to  the 
system  engineers  only  after  this  phase  has  been  passed  successfully. 

For  efficiently  supporting  this  type  of  testing  we  built  a  so  called  Avionics 
System  Software  Rig  (ASSR  for  the  weapon  system  Tornado,  see  Fig. 3) .  It  consists 
of  all  relevant  avionics  ccmputers  connected  as  in  the  real  system,  all  controls 
and  displays  essential  for  this  testing,  plus  software  loading  and  test  support 
devices.  In  case  of  problems  with  a  specific  computer  and  its  software  the 
corresponding  conpiter  test  bench  may  be  linked  to  the  ASSR  to  allow  for  indepth 
testing  of  this  specific  item. 


Fig.  3  Avionics  System  Software  Rig 


4.  Eqierlenoes  frcm  Current  Projects 


The  methods  and  tools  described  above  have  been  used  and  are  still  being  used 
in  three  major  aircraft  programs  of  our  company: 

-  P-4P  Improvement  of  Combat  Efficiency;  a  GE  only  program  involving  the 
Integration  of  a  new  radar,  of  a  new  A/A  missile,  of  an  additional  mission 
computer  and  the  inprovement  of  the  navigation  system; 

-  HARM  integration  with  IDS  Tornado;  a  partly  trinational  program  involving 
integration  of  an  anti -radiation  missile,  of  an  improved  missile  control 
computer,  of  an  improved  radar  warning  equipment  and  of  an  improved  stores 
management  syston; 
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-  Electronic  Combat  Reconnaissance  Tornado  (QE) ;  a  partly  trinational 
prc^cram  introducing  a  new  Tornado  variant  for  electronic  combat  and 
penetrating  reconnaissance. 

Eiqieriences  gained  in  these  programs  having  relevance  to  software  development 
will  be  given  below. 

For  systems  development  as  a  whole,  a  "front  end  investment"  of  effort  is 
necessary  to  reduce  technical  risk,  to  deliver  the  required  quality  and  to  get 
realistic  development  schedules.  System  and  software  prototyping  are  therefore 
Indispensable.  W.r.t.  software  we  are  increeisingly  using  the  System  Prototyping 
Rig  to  prototype  critical  software  modules  and  to  evaluate  the  performance  of 
software  developront  environments  before  applying  them  to  real  projects. 

It  is  also  very  important  in  early  phases  of  a  project  to  define  how  the 
performance  of  the  system  will  be  demonstrated  to  the  customer,  because  this 
will  influence  both  system/ software  design  ar»d  overall  costs.  As  such,  test  tool 
requirements  -both  hardware  and  software-  have  to  be  defined  in  parall  to  the 
software  requirements  analysis  and  the  Software  Test  Plan  has  to  be  established 
during  the  software  top  level  design  phase. 

Modern  software  development  methodolc^ies  tend  to  postpone  real  time  aspects  to 
the  detailed  design  phase.  This  might  be  appropriate  for  business  confuting, 
but  for  avionics  applications  this  proved  to  cause  problems.  There  are  cases 
vdiere  the  software  design  had  to  be  radically  changed  because  of  too  extensive 
hlerarchlal  decomposition  and  the  resulting  execution  time  overhead.  In  another 
case,  the  slnplest  and  most  straightforward  software  design  led  to  prohibitive 
execution  times  and  an  increase  in  data  records  required.  As  mentioned  before, 
the  methods  and  tools  do  not  support  effective  control  of  real  time  behaviour 
during  software  requirements  analysis  and  software  top  level  design.  One 
therefore  has  to  extrapolate  this  aspect  from  known  systans  during  these  early 
liiases;  or  for  conpletely  new  systems  carry  out  a  prototyping  exercise  for 
critical  modules. 

There  is  another  potential  problem  when  using  state  of  the  art  software 
development  tools  in  that  they  support  the  documentation  of  the  lowest  levels  in 
great  detail,  but  facilities  to  support  an  easy  understandable,  ccoplete 
overview  are  missing.  One  of  the  reasons  is  that  the  tools  In  general  store 
information  in  an  object  oriented  way,  i.e.  objects  being  functions  stored 
according  to  their  place  in  the  overall  functional  hierarchy.  Combining  the 
description  of  eawh  of  these  functiois  into  one  document  (for  example  the  Top 
Level  Design  Document)  -a  facility  tl»  tools  are  offering-  does  not  necessarily 
lead  to  a  readable  document.  One  major  element  of  a  good  document  is  not 
provided  autcxnatlcally  by  the  tool:  a  useful  introduction/overview.  In  addition, 
such  collections  of  functions  tend  to  get  prohibitively  large  (one  of  our 
examples:  Software  Requirements  Specification:  400  Pages;  Top  Level  Design 
Document:  2000  pages;  Detailed  Design  Document:  6  700  pages!)  and  very  hard  to 
read.  As  a  basis  for  the  Critical  Design  Review  or  the  Detailed  Design  Review 
they  are  of  very  limited  use  only.  One  therefore  has  to  carefully  control  that 
the  information  of  the  systan  is  stored  efficiently  in  the  tool  database.  A 
useful  overview  may  be  obtained  by  describing  the  full  system  in  the  first  or 
first  two  levels  of  the  design  hierarchy  down  to  a  useful  depth  and  thus 
manually  introducing  redundant  but  urgently  required  information  into  the 
database. 

System  Software  Testing  calls  for  a  precise  synchronisation  of  the  software 
development  in  each  computer:  all  software  paclcages  of  all  computers  have  to 
arrive  at  the  same  time.  This  is  not  realistic.  The  testing  method  applied 
therefore  has  to  be  flexible  enough  to  allow  for  partial  system  integration  by 
simulating  the  not  available  conputers.  The  prototypes  created  during  the 
initial  system  phases  may  also  be  helpful  here. 
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VIhen  using  the  methods  described  in  para  2*3  supported  by  appropriate  tools 
one  carefully  has  to  consider  eonpiting  power  ri^t  at  the  beginning  because 
conputers  used  nowadays  for  avicmics  still  have  limited  ressources,  i.e.  memory 
capacitiy  and  eonpiting  speed.  On  the  other  hand  the  methods/ tools  are  demanding 
in  these  ressources.  One  conpiex  task  originally  written  in  an  optimised 
Assadiler  has  been  rewritten  for  a  new  conpiter  in  one  of  our  projects.  The 
first  try  resulted  in  a  memory  increase  from  25  KW  to  200  KW  and  an  increase  in 
execution  time  from  10  msec  to  300  msec.  Execution  time  overhead  has  been 
decreased  considerably  in  the  meantime,  but  memory  overhead  is  essentially  the 
same.  Avionics  systems  with  embedded  eoopiters  should  therefore  be  designed  with 
maximum  growth  protential  to  avoid  costly  Iterations. 

The  experiences  gained  so  far  indicate  a  significant  improvement  of  productivity 
vdien  applying  methods  and  tools  as  of  para  2  &  3.  Explicit  figures  are  available 
for  the  software  requirements  analysis  i^iase.  Conparing  the  costs  for  one  page 
of  a  specification,  the  costs  dropped  by  a  factor  of  3  to  4.  On  the  other  hand, 
due  to  generous  formatting  and  additional  information  provided  within  the 
specifications,  they  are  from  1.5  to  2  times  larger  than  they  were  before.  The 
productivity  increase  therefore  is  at  least  a  factor  of  1.5.  The  costs  for 
software  design,  inplementation  and  test  are  difficult  to  compare  at  present. 
But  in  the  near  future  we  will  have  a  nice  test  case:  the  same  requirements  will 
be  Implemented  in  one  computer  in  the  "old  fashioned"  way  in  Assembler  and  in 
parallel  in  another  one  using  the  new  methods  and  a  high  order  language. 

In  order  to  carry  out  system  and  software  development  in  a  cost  effective  way, 
everybody  Involved  must  have  a  full  understanding  of  the  development  process/ 
model  and  of  his  contribution  to  it.  This  requires  besides  training  enough  time 
to  get  acquainted  to  the  new  methods  before  starting  time  critical  projects.  In 
addition  at  least  some  of  the  systems  engineers  have  to  be  familiar  with  the 
principles  of  software  development  and  some  of  the  software  developers  with  the 
principles  of  systems  engineering.  The  more  information  is  exch^ed  between 
them  the  better  the  final  product  will  be. 

Finally  let's  consider  some  additional  experiences  gained  in  international 
projects.  First  of  all,  because  in  general  part  of  system  and  software 
development  are  located  at  different  sites  (partner  companies)  it  is  essential 
to  Introduce  the  same  methodology,  the  same  understanding  of  it  and  the  same 
tools  at  all  sites.  The  workshare  of  centralised  teams  and  the  partner  companies 
have  to  be  precisely  defined  and  known  to  everybody  involved. 

So  far,  international  software  for  one  computer  has  always  been  designed, 
In^lemented  and  tested  in  one  centralised  team.  Applying  a  more  rigid  approach 
nowadays,  we  are  trying  to  at  leaist  weaken  this  requirement.  Whether  this  will 
be  of  success  has  to  be  demonstrated  yet.  On  the  other  hand  software 
requirements  analysis  and  system  integration  test  have  been  carried  out  in  a 
decentralised  manner  for  several  years. 

Defining  Software  Requirement  Specifications  at  different  sites  asks  for  an 
efficient  distributed  database.  A  direct  link  of  the  host  conputers  at  the 
different  sites  has  not  been  realised  so  far  due  to  security  problems. 
The  way  being  pursued  at  present  is  to  have  local  databases  at  the 
development  sites  that  are  integrated  from  time  to  time  by  a  central  team  to 
form  the  central  master  database.  The  latter  is  then  distributed  to  all  sites 
and  forms  the  basis  for  the  next  development  step. 


5>  Ritentlal  Imwoveaents 


When  considering  the  experiences  we  have  got  with  our  methodology  and  tools 
for  system  development,  the  following  areas  for  potential  inprovanent  in  the 
software  development  field  emerge. 
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The  methodology  as  such  proved  to  be  very  useful  and  only  minor  corrections  ewe 
deoned  necessary.  However,  the  support  of  the  tools  for  this  methodology  is  best 
for  the  coding  ifivase  and  decreases  steadily  the  more  apart  the  considered  phase 
is  from  this  one.  To  start  with  real  time  aspects,  we  would  like  to  have  a 
better  method  and  a  tool  supporting  us  in  providing  estimates  for  throu^put  and 
memory  requirements  as  early  as  possible.  In  addition,  the  tool  support  to 
describe  iid  analyse  real  time  features  in  the  software  requirements  analysis 
phase  has  to  be  improved. 

The  documentation  the  tools  are  providing  is  another  area  that  asks  for 
improvement.  The  documents  should  not  just  consist  of  a  collection  of 
hierarchically  ordered  objects  and  a  list  of  contents,  they  should  be  structured 
in  such  a  way,  that  both  an  easy  readable  overview  and  all  the  details  are 
available.  This  is  especially  important  for  the  Top  Level  Design  Document  in 
order  to  be  able  to  carry  out  a  useful  Preliminary  Design  Review  (PDR). 

At  present  the  verification  of  the  performance  of  the  system  or  the  software  is 
a  very  hard  job,  essentially  carried  out  manually.  The  complexity  of  nowadays 
systems  and  their  software  asks  for  a  considerable  improvement  of  the  tools  to 
allow  for  a  cross  check  of  requirements  and  the  corresponding  test  procedures, 
to  automatically  derive  test  data  sets  and  test  steps  out  of  software  require¬ 
ments  specification  or  the  software  design  specifications. 

Last  but  not  least,  the  user  interface  of  tools  needs  to  be  improved.  A  system 
engineer  drawing  data  flow  diagrams  on  a  sheet  of  paper  in  10  minutes  will  not 
be  prepared  to  use  a  tool  for  the  same  purpose,  if  it  then  takes  half  an  hour  or 
even  more.  If  he  in  addition  might  have  to  use  different  user  interfaces  for 
different  phases  of  development  this  becomes  even  worse.  So  what  is  required  is 
a  universal,  easy  to  learn  user  interface  for  all  phases  of  development. 

We  hope  that  this  contribution  cam  help  to  stimulate  the  discussion  between  the 
systems  engineer  and  the  software  developer  and  provides  some  hints  for  improve- 
mients. 


DISCUSSION 


A.BIooiBficld,  UK 

Wha!  specific  tools  are  used  by  MBB  to  support  documentation? 

Author's  Reply 

For  Software  Requirement  Specifications  we  are  using  EPOS  and  PROMOD. 


M^toll,  Fr 

You  mentioned  a  speciftcation  written  in  a  formal  langu^e.  Can  you  expand  on  that? 

Author’s  Reply 

We  used  Structured  Analysis  as  a  method.  The  corresponding  tools  like  PROMOD,  which  we  are  using,  need  a  unique, 
unambiguous  representation  of  the  system  or  the  software  requirements.  The  formal  elements  used  are  data  flow 
diagrams  and  data  dictionaries. 
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SUMMARY 


The  SAFRA  aoftware  developaeoc  iiethod  baa  been  uaed  ertenalrely  and  auceeaafully  for  the  production 
of  real-tine  avionic  ayatena  at  BAe  Warton.  The  method  couplea  a  powerful,  yet  aimple,  aemi-fomal 
apecifieation  (CORE)  and  deaign  (MASCOT)  approach  Co  provide  an  environment  covering  the  cosplete 
lifecycle.  Enbedding  fomal  methoda  into  thia  eatabliahed  approach  will  combine  requirenenta 
capture  and  atructuring  techniquea  with  mathematically  formal  apecifieation  and  dealgns, 
facilitating  mathematical  proof  of  aafety  critical  elementa. 

Following  an  overview  of  SAFRA  Chla  paper  providea  a  brief  introduction  to  formal  methoda  and 
Identiflea  Z,  a  method  founded  on  aet  theory  and  logic,  for  detailed  Inveatigatlon.  An  interface 
between  aemi-formal  and  formal  techniquea  la  defined  and  the  reaulta  of  applying  the  combined 
method  to  a  number  of  avionic  apecifieation  atudlea  are  aummariaed  and  dlacuaaed.  The  paper 
concludea  by  eonaiderlng  the  potential  benefita  and  coata  of  adopting  formal  methoda  on  large 
aeale,  avionic  aoftware  projecta. 

INTRODUCTION 

The  reallaation,  over  a  decade  ago,  that  the  proliferation  of  embedded  ayatem  aoftware  muat  be 
matched  by  Increaaing  productivity  levela  hae  provided  contlnuoua  motivation  for  Britiah  Aeroapace 
Varton  to  appraiae,  adopt  and  evolve  effective  aoftware  development  techniquea.  The  coat  leverage 
inherent  in  an  ability  to  eliminate  errora  early  in  the  aoftware  lifecycle,  using  more  formal 
methoda  of  expreaaion,  led  to  an  approach  entitled  Semi-Automated  Functional  Requirements  Analyals 
(SAFRA  Ref  1).  This  approach  was  matured  and  proven  on  a  large  scale  project  called  the 
Experimental  Aircraft  Program  (EAP),  a  collaborative  European  project  undertaken  lo  demonatrate  the 
advanced  technologies  required  for  the  next  generation  of  fighter  aircraft.  These  technologies 
included  multi- function  displays  and  controls  in  an  all  electronic  cockpit  and  a  Utility  Systems 
Ksaagemeat  (USM)  system  including  fuel  gauging,  propulsion,  hydraulics  etc.  The  EAP  computet 
hardware  system  architecture  comprised  a  suite  of  general  purpose  microprocessors  communicating 
primarily  via  KIL-STD-1553  serial  data  highways.  (See  Ref.  2  for  a  detailed  description). 

SAFRA  is  now  regarded  as  a  Ist  generation  approach,  the  benefits  of  which  have  been  clearly 
established  and  quantified.  Over  recent  years  the  general  development  of  languages  and 
environments  has  combined  with  enhanceaMnta  to  SAFRA  to  evolve  a  2nd  generation  approach,  currently 
being  transferred  onto  projects  such  as  the  European  Fighter  Aircraft  (EFA).  Increasing  the  levels 
of  expressed  formality  used  in  raqulremente  enalysie  and  specification  is  one  area  of  development 
which  haa  been  partially  Implemented  in  the  2nd  generation  approach  and  which  will  fundamentally 
underpin  advanced  3rd  generation  tachnlquea  such  aa  rapid  prototyping,  animation  and  large  scale 
re-uee.  (Ref.  3).  Further  advencea  in  early  elimination  of  erTors,  and  hence  productivity,  will 
accrue  from  these  advances. 

Aa  a  drlvar  for  Increaaing  lavels  of  formality  within  raqulrementa  and  specifications,  the  desire 
to  l^irove  productivity  is  more  than  matched  by  the  obligation  to  eliminate  software  faults  from 
■yatems  whosa  functions  are  depended  upon  for  safety.  Software  in  such  systems  is  termed  'safety 
critical'.  Precise,  mathematically  formal  notations  are  becoming  widely  recognised  as  being  the 
most  appropriate  for  the  expreaaion  of  safety  requirements.  They  are  also  regarded  se 
prerequisites  for  stcemptsd  proofs  of  softwars  corrsetnsss. 

This  papar  dsacrlbsa  some  eellent  eapects  of  work  performed  recently  at  British  Aerospace  (BAs) 
Varton  dirsetsd  towards  integrating  a  mathsmatlcaXly  formal  notation  for  aoftware  apecifieation 
with  an  establiahad  aeml-formal  approach.  The  SAFRA  techniques  ere  outlined  with  an  explanation  of 
the  kay  concepts.  Requlremanta  txpreaalon  aspects  of  SAFRA  are  highlighted  in  the  form  of  CORE  - 
Controlled  Requirements  Expression.  A  brief  introduction  to  mathematically  formal  software 
apecifieation  mathods  is  given.  The  relationship  of  a  particular  method,  Z,  to  CORE  is  explored. 
A  co^lned  method  is  proposed  -  FORMAL  CORE  -  and  Its  application  to  evaluatory  but  representative 
caae  studies  ia  datailed.  Fast  experiance  of  tha  introduction  of  new  methods  onto  projects  la 
sxtrapolstsd  to  sntleipsts  likely  costs  of  adoption  and  these  ere  weighed  qualitatively  against 
potential  benaflta, 

SAFRA 

Tha  philosophy  adopted  for  SAFRA  was  that  aach  phase  of  the  software  lifecycle  must  be  supported  by 
s  method  and  that  each  mathod  or  cschnlqus  ia  supported  by  s  corresponding  tool.  The  methods  and 
tools  used  to  develop  the  EAP  software  are  shown  in  Figure  1.  Sines  Me  wee  essentially  its  own 
customer  on  this  project  no  external  rsqulramant  or  apaclflcatlona  sxiatad.  Systams  Enginsaritig 
dapartmsnta  produced  functional  raquiremants  and  software  specifications.  *n)srs  was  then  an 
intsrfscs  to  Software  Englnssring  dspsrtmsnts  who  embodied  those  requirements  through  basic  and 
dstallsd  daalgn  into  cods.  Hhsrs  no  methods  or  tools  existed  new  ones  were  developed.  In 
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p«rtlcul«r,  considerable  developaant  vaa  undertaken  to  produce  CORE,  supported  by  a  workstation. 
CORE  eabracea  the  lifecycle  froa  functional  requlreaeota  through  to  the  production  of  detailed 
designs.  On  the  other  hand,  where  tools  were  known  to  exist,  they  were  laported  and  Integrated,  k 
brief  overview  of  the  aethods  and  Cools  other  Chan  CORE  la  given  here,  Che  CORE  aethod  Is  described 
in  the  next  section. 

In  addition  to  syntax  and  other  checks  which  can  be  performed  on  the  Workstation,  CORE  products 
were  subjected  Co  a  acre  detailed  analyals  using  a  tool  called  PSL/PSA.  (A  product  of  META  Systeas 
Ltd.  (d/b/a  ZSOOS  Inc.)  }  PSL  Is  a  coaputer  processable  language,  capable  of  describing  a  variety 
of  behavioural  and  architectural  aspects  of  systeas  with  a  range  of  object  and  Inter-relatlonshlp 
definitions.  PSA  allows  an  overall  systea  requlreaents  database  to  be  established  and  provides 
checking  and  analysis  facilities  In  the  fora  of  various  reports. 

The  software  design  phase  Invoked  the  continuing  use  of  CORE  notation  to  produce  coapleCely 
structured  detailed  specifications  within  the  framework  of  a  rationalised  executive  and  high  order 
language.  The  former  was  Che  Modular  Approach  to  Software  Construction,  Operation  and  Test 
(MASCOT)  (Ref.  4)  and  Che  latter  for  EAP  was  PASCAL. 

In  SAFRA  Che  output  of  Che  requlreaents  phase  using  CORE  was  Integrated  in  such  a  way,  Chat  a  basic 
design  was  derived  by  transforming  CORE  requirement  thread  diagrams  into  a  MASCOT  design. 
Experience  Indicates  that  sufficient  systems  analytical  and  structuring  work  must  be  done  to  ensure 
ease  of  transition  at  this  stage.  Detailed  design  for  the  individual  processes  (MASCOT 
’activities')  Involved  what  la  In  normal  teras  'structured  program  design'  but  in  CORE  teras  is 
called  layered  decomposition. 

The  software  basic  design,  detailed  design,  construction  and  test  phases  made  use  of  the 
PERSPECTIVE  software  prograving  support  environment  (a  proprietary  product  of  Systeas  Designers 
PLC.),  PERSPECTIVE  Is  aimed  specifically  at  supporting  the  development  of  software  for  embedded 
coaputer  systems  written  in  PASCAL  with  reel-time  extensions  and  provides  a  aultl-user/multl-access 
host/target  envlronaent  for  large  and  small  programming  teams. 

To  ensure  coaiplete  support  for  sof tware/hardware  Integration  and  in  particular  the  support  of 
run-time  system  development,  embryonic  target  workstations  were  Included  a  Che  approach  In  the 
form  of  'Mlcro-proceaaor  Development  System  (MDS)  equipment,  which  provided  Important  performance 
and  analyals  Information. 

CORE 

The  backbone  of  Che  EAP  methodology  and  toolset  was  CORE.  (Ref.  5).  CORE  is  a  method  of 
cxprcaalng  and  analysing  requirements  In  s  controlled,  structured  and  primarily  diagrammatic 
manner.  The  method  comprises  ll  logical  steps  «rhlch  when  applied  to  a  requirement  will  decompose 
it  Into  lower  level  components  to.  idtlch.  In  cum,  the  method  can  be  applied.  The  11  steps  are 
listed  and  a  complete  deaerlptlon  and  comparison  with  ocher  techniques  given  In  Ref.  6  -  only  a 
brief  summary  Is  given  here. 

The  dlsgraanatlc  notation  of  CORE  is  based  principally  on  the  depletion  of  data  flow  between 
processea.  As  shown  in  Figure  2,  processes  are  represented  by  boxes  with  input  data  lines 
terminating  on  the  left  edge,  output  data  lines  originating  from  the  right  edge  and  control  (or 
sclmulatlon)  data  lines  terminating  on  Che  top  edge.  All  data  lines  are  classed  as  either  critical 
or  non-crlclcal.  Critical  data  flow  between  processes  implies  that  sender  and  receiver  processes 
set  In  s  constrained  way  so  that  every  data  item  'sent*  Is  'received'  and  used.  Non  critical  data 
flow  places  no  restriction  on  the  activation  of  sender  and  receiver  processes.  Whilst,  at  first 
sight,  this  does  not  appear  to  be  a  strong  concept.  It  Is  a  key  to  CORE'S  utility,  particularly 
when  applied  to  structuring  the  requirements  of  large,  real-time  software  systems. 

The  CORE  method,  which  results  in  a  diagrammatic  representation  of  requirements,  embodies  a  number 
of  key  concepts  -  viewpoints,  tabular  entries,  data  decomposition,  threads,  combined  threads, 
layering,  structured  design  note,  operational  diagrams.  Those  concepts  most  relevant  to  the 
subsequent  discussion  on  formal  methods  are  picked  out  and  briefly  described  here. 

When  capturing  the  requirements  of  a  system  two  types  of  viewpoint  are  used.  Firstly  the  direct, 

external  Influences  on  the  system  (e.g.  users,  other  systems,  . )  are  grouped  Into  3  or  4 

'bounding  viewpoints'.  (Figure  3).  For  each  such  viewpoint,  and  for  the  system  Itself  (also 
treated  as  a  viewpoint)  a  'tabular  entry*  is  created,  comprising  a  list  of  high  level  actions 
performed  by  Che  viewpoint.  Each  action  is  annotated  with  high  level  or  abstract  data  Items 
consumed  and  produced,  together  with  their  source  and  destination  viewpoints.  In  this  way 
information  is  gathered  about  Che  system,  its  environment  and  information  flow  across  the  system 
boundary.  Secondly  the  system  itself  la  decomposed  or  partitioned  by  identifying  3  or  4  'defining 
viewpoints'  within  It.  This  process  continues  hierarchically,  each  viewpoint  being  split  Into  3  or 
4  further  viewpoints,  so  chat  a  viewpoint  tree  structure  Is  created  within  which  requirements  can 
be  expressed  and  reconciled.  (Figure  4).  Working  down  the  tree  tabular  entries  are  created  for 
each  viewpoint,  thus  gathering  Information  about  the  functions  of  the  system  in  a  logical  and 
controlled  manner.  Information  flow  between  viewpoints  sC  Che  same  level  is  checked  for 
consistency  and,  where  appropriate,  data  dec<»poBltlon  diagrams  are  provided  to  display  the 
Internal  structure  of  abstract  or  high  level  data  items.  Final  stages  of  viewpoint  selection  may 
Involve  Identification  of  hardware  sub-systems  or  components. 

Viewpoint  selection,  at  any  level,  stimulates  the  creation  of  tabular  entries  -  lists  of  actions 
which  each  viewpoint  performs  -  at  an  appropriate  level  of  detail.  Subsequent  steps  in  the  method 
investigate  relationships  between  and  ultimately  modify  these  actions,  both  within  and  across 
viewpoints. 
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Within  «  viewpoint  every  dace  Item  In  the  tabular  entry  la  considered  and  caCegorlaed  critical  or 
non-erltlcal.  There  nay  Chen  be  eoM  actlona  within  a  viewpoint  which  are  Interconnected  by 
critical  data.  Where  thla  occura  these  processes  are  replaced  by  a  single  action  or  process.  The 
resulting  set  of  actions  are  called  threads  -  there  le  no  critical  data  flow  between  then  and  some 
nay  be  conposltes  of  origlnal»  tabular  entry  actions,  ‘nils  exercise*  therefore*  Identifies  parts 
of  the  syaten  (within  a  viewpoint)  which  can  aerate  without  close  synchronisation,  since  these 
parts  will  only  he  interconnected  by  non-critical  data.  The  execution  of  the  receiver  process  or 
activity  Is  not  tied  to  the  execution  of  the  tranenlttlng  process  or  activity. 

When  actions  have  been  reconciled  to  thraads  within  all  3  or  4  of  a  group  of  viewpoints  the 
exercise  Is  generalised  to  Identify  'threads  of  threads*  (conblned  threads)  eonprlslng  threads 
within  different  viewpoints  linked  by  critical  data  flow  across  vle«rpolnt  boundaries.  (Figure  5). 
This  activity  pin-points  areas  of  functionality  In  the  syeten  which  require  to  be  closely  coupled 
by  buffers*  queues  or  Interleaving  execution*  and  where  data  are  preserved  as  they  flow  froa  one 
activity  to  another. 

Within  CORE  the  functional  behaviour  of  processes  Is  specified  using  a  conblnation  of  two 
techniques,  graphical  and  algorlthnlc.  The  graphical  notation  extends  the  basic  'box  and  line' 
fomat  already  described  with  additional  syabols  and  constructs  enconpasslng  box  decowposltlon* 
iteration,  nutual  exclusion  and  functional  equivalence.  Each  dlagrsn  box  is  also  supported  by  a 
'structured  design  note'  wherein  algorlthnlc  reletlonshlps  between  process  Input*  output  and  local 
data  Itens  Is  recorded.  The  algorithmic  notation  awy  be  descriptive*  narrative  at  high,  abstract 
levels  of  the  viewpoint  tree  or  It  nay  be  a  detailed,  pseudo-code  representation  of  a  function  at 
low  levels  of  the  tree.  This  conblnation  of  dlagrannatlc  layering  and  algorithmic  notations  Is 
used  to  specify  requirements  at  a  detailed  level,  within  a  framework  of  vletrpolnts  and  threads 
which  encapsulates  requirements  for  synchronisation,  coupling  and  temporal  interactions  of  the 
basic  processes  or  actions. 

Whilst  there  are  a  number  of  additional  aspects  of  the  CORE*  ll  step  method  which  cannot  adequately 
be  detailed  here*  the  points  most  relevant  to  subsequent  discussion  have  been  highlighted.  In 
summary  CORE  Is  a  structured  method  within  a  primarily  diagrammatic  notation.  When  applied  to 
real-time  control  systems  and  their  environments  It  facilitates  and  supports  the  capture  of 
functional  requirements*  the  definition  of  software  requirements  and  the  decomposition  of  the 
overall  software  function  Into  loosely  coupled  processes. 

FORMAL  METHODS 


Steadily  over  a  numbec  of  years,  and  prollflcally  over  recent  years*  new  methods  of  software 
specification  and  development  based  on  pure  mathematics  have  been  emerging  from  academic  and 
Industrial  Institutions.  The  activation  for  employing  mathematically  formal  notations  and  methods 
to  the  specification  and  development  of  software  is  Identical  to  the  motivation  for  employing 
structured  methods  such  as  CORE  -  namely  the  rcaK)val  of  errors  early  In  the  production  process  both 
to  Improve  the  quality  of  delivered  software  and  to  Increase  the  productivity  of  software 
engineers. 

The  term  'formal  method'  Is  widely  used  in  varying  contexts.  Hence  we  list  the  principal  aspects 
or  components  of  a  formal  method  as  discussed  In  this  paper. 

.  A  mathematical  notation  and  set  of  rules 

A  specification  structuring  method 

.  A  method  of  proving  completeness  and  self  consistency  of  a  specification 

A  method  of  'refinement*  whereby  an  abstract  specification  is  transformed  or  reified 
into  e  progrjmmlng  language  Implementation 

A  method  of  proof  of  refinement  steps 

The  branches  of  mathematics  which  are  common  to  most  of  the  notations  and  methods  developed  so  far 
are: 


.  Logic  end  predicate  calculus  -  as  an  enhancement  of  Boolean  operators*  types  and 

rules  coBion  to  many  prograanlng  languages 

Sat  theory  -  as  s  method  of  specifying  operations  on  collections  of 

data  In  a  manner  which  Is  Independent  of  the  method  of 
storage  of  the  data  in  a  computer 

The  key  to  effective  use  of  these  branches  of  msthrastlcs  Is  abstraction  -  l.s.  the  statement  of  a 
requirement  In  s  form  which  Is  Independent  of  the  notations  and  restrictions  of  any  software 
Implementation  language  -  the  use  of  s  'problem  notation*  rather  than  a  'solution  notation*  -  the 
oft  quoted  (but  succinct)  'what*  rather  than  'how*. 

In  addition  to  Improving  the  quality  and  precision  of  specifications,  formal  methods  offer  the 
prospect  of  combining  with  programming  languages,  proven  to  be  mathematically  self-consistent  and 
well  defined,  to  allow  mathematical  proof  that  a  'solution*  embodied  In  a  programme  satisfies  s 
requirement  stated  in  a  formal  specification  notation.  Whilst  currently  feasible  only  for  small 
systems,  the  prospect  of  proving  an  Implsmentstlon  of  s  safety  critical  function  against  s  clear, 
prsclss  and  concise  specification  Is  a  strong  motivation  for  active  Involvement  In  this  field.  The 
Increasing  adoption  of  computer  hardware  In  safety  critical  avionic  systems  has  generated  such 
Involvement  at  BAe  Wsrton. 
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It  is  not  possible  here  to  give  a  coapreheoalve  overview  of  the  forval  Methods  field,  rather  we 
conceacraCe  on  what  is  widely  regarded  as  the  aost  mature  class  of  methods  *■  the  model  based 
specification  techniques,  of  %rhlch  the  Vienna  Develofment  Method  (VM  -  Reference  7)  and  Z 
(Reference  8)  are  the  aost  extensively  used  in  Industry > 

The  model  based  techniques  have  a  comon  structure  which  Involves  the  definition  of  a  'state*  to 
model  the  Internal  structure  (or  memory)  of  the  system.  (Figure  6).  The  state  is  modelled  as 
abstractly  as  possible  using  mathematical  sets  or  higher  level  objects  such  as  sequences  and 
mappings.  The  aim  Is  to  encapsulate  essential  features  of  the  system  without  Introducing 
unnecessary  implementation  details.  Operations  are  defined  which  may  depend  upon  and  affect  the 
values  of  the  state  components  and  may  also  depend  upon  'external*  Input  variables  and  may  generate 
'external'  output  variables.  This  structure  Is  common  to  all  types  of  applications,  from 
transaction  processing  and  database  systems  to  plant  control  and  monitoring. 

After  defalled  appraisal,  Z  was  selected  as  the  subject  of  an  extensive  prograame  of  work  aimed  at 
Investigating  Its  relationship  to  and  possible  Integration  with  the  CORE  based  SAFRA  methodology. 
Z  is  a  product  of  the  Programing  Research  Group  at  Oxford  University  and  comprises  a  prlmrlly 
set-theoretic  notation  extended  to  define  relations,  functions,  sequences,  etc.  and  associated 
operators.  Data  typing  In  terms  of  these  entitles  Is  complemented  by  propositional  and  predicate 
calculus  to  yield  a  notation  %rhlch  Is  expressive  and  extendible. 

Particular  strengths  of  Z  are  its  structuring  facilities  and  Its  presentational  clarity. 
Structuring  Is  provided  by  a  'schema'  notation  (Figure  7)  whereby  a  complete  specification  Is 
constructed  by  defining  and  combining  a  number  of  schema  operations,  each  representing  some  partial 
aspect  of  the  overall  requirement.  A  Z  schema  comprises  two  parts 

.  the  signature  -  a  declaration  of  the  names  and  types  of  variables  Involved  in  the 
operation 

.  the  predicate  -  a  mathematically  stated  relationship  between  the  elements  of  the 
signature 

The  predicate  often  takes  the  form  of  an  explicit  'pre-condition*  -  a  statement  which  must  be 
satisfied  for  the  operation  to  be  Invoked  -  and  an  explicit  'poat-condltlon'  -  a  statement 
describing  Che  effect  of  the  operation.  The  set  of  partial  operations  can  be  formally  analysed  for 
completeness  and  self-consistency  to  produce  a  robust  set  of  operations  embodying  the  requirements. 
Presentational  clarity  derives  partially  from  the  schema  structuring  and  partially  from  the 
Intersperslon  of  descriptive,  narrative  text,  used  to  complement  the  mathematical  formality  and 
render  the  specification  'readable',  even  by  those  unfamiliar  with  Z. 

Vhllsc  enjoying  increasing  use  in  industry  the  Z  notation  and  method  are  not  rigorously 
standardised  nor  adequately  supported  by  tools.  There  are  also  strict  limits  to  the  scope  of 
applicability  of  Che  method,  especially  In  the  area  of  real-time  control  systems.  Large  scale 
structuring,  process  synchronisations  and  temporal  aspects  in  general  are  not  supported. 

In  sumnary  formal  methods  offer  a  further  Increase  in  expressions!  formality  beyond  Chat  already 
achieved  by  Che  adoption  of  structured  methods  such  as  CORE.  The  model  based  or  'constructive* 
class  of  methods  is  Che  most  established  and  widely  used.  Z  was  selected  by  BAe  Warton  for 
detailed  evaluation  and  possible  Integration  with  CORE. 

FORMAL  CORE 

It  is  clear  from  the  previous  two  sections  that  Che  strengths  of  CORE  may  be  complemented  by  those 
of  Formal  Methods  In  the  application  domain  of  large,  real-time  avionic  systems. 

CORE  Is  a  powerful,  structured  method  for  the  controlled  and  modular  development  of  system 
requirements  and  specifications  with  particular  emphasis  on  module  Interaction  synchronlaatlons  and 
temporal  relationships.  MsChemaClcal  formalisation  of  the  temporal  Interactions  of  processes  is 
still  a  research  area,  however  the  loosely  coupled  processes  defined  by  CORE  analysis  are 
potentially  amenable  to  established  formal  specification  methods.  On  EAV  the  functional  content  of 
CORE  threads  was  specified  Informally  (descriptive  narrative)  high  in  the  viewpoint  hierarchy  (l.e. 
early  In  the  lifecycle)  and  seml-formally  (diagrammatic  decomposition  and  pseudo-code)  later  In  the 
lifecycle.  The  use  of  Z  allows  precise,  formal  definition  early  In  the  lifecycle  followed  by 
potentially  verifiable  refinement  thereafter. 

In  this  way  the  concept  of  FORMAL  CORE  was  evolved  as  an  enhancement  to  SAFRA  which  combines  the 
strengths  of  structured  and  formal  approaches.  An  interface  is  proposed  st  the  thread  level  so 
that  all  temporal  aspects  of  requirements  are  captured  within  CORE  and  all  functional  aspects  of 
threads  are  specified  in  Z.  In  order  to  investigate  this  concept  a  nxiaber  of  representative 
threads  were  selected  from  the  EAP  Utilities  Systems  and  formally  li-speclflsd  In  Z,  based  on  an 
understanding  of  the  engineering  requirements  (gained  from  existing  specification  documentation  and 
Interviewing  engineers).  The  epeclf Ications  were  then  refined  to  code  (PASCAL)  before  a  detailed 
comparison  of  both  specification  and  code  was  made  with  the  original,  CORE-based,  EAP 
dociBentatlon. 

Although  the  Utilities  Systsms  threads  chosen  for  study  were  quite  small  (<100  lines  code  when 
implemented)  clear  Indications  of  the  benefits  of  formality  were  seen.  These  prompted  further 
study  In  the  fora  of  a  relatively  large  (2(M>0  lines  of  code)  case  study  which  had  proved 
particularly  difficult  to  specify  and  design  using  standard  CORE  -  nr^ely  Soft-Key  decoding  for  the 
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vultl-fuQction  displays  In  the  all  electronic  cockpit  of  EAP.  Coablnlng  the  results  and 
conclusions  froB  this  series  of  Initial  case  studies  the  follovlng  aaln  points  eaerged: 

.  the  strengths  of  the  foraal  notation  and  aeChod  (precision,  clarity,  verifiability  and 
specification  by  construction)  cocpleaent  the  strengths  of  the  CORE  se«l-foraal  notation  and 
method  (organised  requirements  capture,  techniques  for  handling  dynamics,  temporal  aspects, 
concurrency) 

.  embedding  formal  methods  in  an  established,  structured  approach  Is  a  viable  way  to  feed 
formality  from  a  research  and  development  environment  through  to  projects 

.  the  formal  definitions  of  a  detain  vocabulary  -  i.e,  a  set  of  formally  defined  functions 
%diich  are  specific  to  the  application  and  used  frequently  -  helps  to  conceal  unnecessary 
detail  In  specifications  and  provides  a  natural  working  language  for  systems  engineers. 

In  all  the  case  studies  the  use  of  the  forget  method  resulted  In  enhanced  clarity,  visibility 
and  traceability  (therefore  vastly  Isqtrovlng  the  prospects  of  effective  maintenance) .  Also, 
notably  these  benefits  were  not  at  the  expense  of  code  else,  performance,  ...  but  in  fact 
were  accompanied  by  a  reduction  in  code  size  together  with  reduced  stack  usage. 

.  more  effort  Is  expended  on  requirements  capture/speclflcatlon  when  a  formal  notation  and 
method  Is  employed.  Less  effort  Is  expended  on  design  and  coding  -  the  refinement  from 
specification  to  cede  being  relatively  straightforward  for  avionic  syscems  which  are  not 
dominated  by  complex  data  structures. 

.  there  Is  s  marked  lack  of  mature  tool  support  for  creating,  analysing  and  refining  formal 
specifications. 

there  la  a  barrier,  at  best  only  perceived  but  probably  real,  on  the  part  of  software  (and 
more  so  systems)  engineers  to  the  introduction  of  mathematical  techniques  into  the  software 
production  process. 

In  addition  It  was  established  that  the  formal  notation  enables  extensive  formal  analysis  of  safety 
critical  system  specifications  to  be  performed  and  chat  formal  specifications  are  pre-requisites 
for  Che  application  of  automated  code  analysis  tools.  Since  a  total  verification  scheme  for  safety 
critical  avionic  software  Is  a  prime  goal  of  research  at  BAe  Uartor  we  expand  here  on  Che 
verification  aspects  of  the  case  study  findings. 

VerlClcacion  through  the  standard  'waterfall*  lifecycle  is  taken  to  be  i>  the  confirmation  that 
any  level  satisfies  its  specification  (l.e.  the  next  higher  level)  and  ii)  the  confirmation  of 
logical  completeness  and  self-consistency  at  Che  highest  level  of  requirements/speclflcatlon. 
These  two  aspects  are  created  separately. 

I)  Throughout  the  case  studies  the  translation  from  a  formally  specified  EAP  CORE  thread  to  a 
functional  implementation  In  PASCAL  was  found  to  be  straight  forward  enough  to  be  a  I  or  2 
stage  process,  the  two  main  aspects  of  which  are  logic  processing  and  the  reusable  functions 
of  the  'domain  vocabulary*.  Once  coding  structures  are  established  for  basic  logical 
constructs  (•>  implies,  <•>  if  any  only  If,  etc..)  the  correspondence  between  logic 
processing  specification  and  code  can  be  checked  rigorously  by  Inspection.  The 
correspondence  between  specification  and  code  for  reusable  functions  is  generally  more 
complex*  involving  code  loops  etc.,  and  proofs  Involving  recursion/induction  are  formulated. 
This  area  of  work  Is  continuing  and  being  combined  with  the  use  of  commercially  available 
semantic  analysis  tools  which  are  used  to  automate  and  assist  the  process  of  proof  of  code 
against  specification. 

II)  The  proof  of  logical  completeness  and  self  consistency  of  a  formally  specified  CORE  thread 
has  been  addressed  with  encouraging  results.  Considerable  analytical  effort  and  expertise  Is 
required  and  it  is  considered  practically  feasible  to  apply  such  a  depth  of  analysis  only  to 
safety  critical  functions.  Nevertheless  significant  progress  Cowards  establishing  a  total 
verification  scheme  has  been  achieved  through  the  investigation  of  formal  specifications  and 
refinement  methods  in  conjunction  with  CORE. 

CONCLUSIONS 

Over  recent  years  British  Aerospace  Warton  have  achieved  a  firm  base  of  experience  in  the 
application  of  structured  software  engineering  techniques  to  the  production  of  embedded  avionic 
software.  The  adoption  of  theae  techniques  significantly  increased  productivity,  enabling  timely 
completion  of  the  large  scale  EAP  project.  Increased  productivity  was  accompanied  by  Increased 
quality,  the  error  rate  of  code  delivered  to  test  rigs  being  reduced  by  a  algnlflcant  factor  over 
previous  projects.  SAFRA,  and  the  more  formal  method  of  expression  provided  by  CORE  in  particular, 
enabled  the  elimination  of  errors  early  in  the  software  lifecycle  and  is  primarily  responsible  for 
the  quantified  achievements. 

The  volume  software  content  of  current  and  future  projects  rises  steeply  over  that  in  EAP  and  hence 
Improved  techniques  must  provide  further  improvements  In  productivity.  The  investment  of  safety 
critical  functions  in  software  is  also  unavoidable  and  hence  the  best  software  engineering 
practices  must  be  adopted  In  order  to  minimise  the  occurrence  of  errors.  These  two  requirements 
have  motivated  an  active  research  prograMe  to  further  increase  levelrt  of  formality  in  SAFRA  by 
incorporating  an  established,  mathematically  formal  specification  method,  Z,  into  CORE. 
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R««Xl«tlc»  cvlonlc  c«s«  atudlcs  fro*  E&P  ti*v«  b*ea  eoapletcd  with  positive  Indications  of  potential 
benefits.  Clarity,  visibility  and  precision  of  specifications  was  enhanced  -  attributes  which 
engender  the  early  Identification  of  errors  and  inconsistencies.  Traceability  fron  requirements 
through  to  co<^e  was  enhanced,  thereby  l^rovlng  the  prospects  of  effective  maintenance.  In 
addition  a  formal  statement  of  requirements  enables  mathenmtlcal  proof  of  code  against 
specification  -  a  prime  objective  for  safety  critical  functicna. 

The  potential  benefits,  therefore,  are  clear.  The  potential  costs,  however,  are  more  esoteric. 
The  Introduction,  by  education,  training  and  experience,  of  formal  mathematical  techniques  into  the 
software  production  process  will  require  sound  management  and  motivation.  The  barriers  that  exist 
have  been  partially  overcome  by  the  auccesaful  adoption  of  CORE,  but  the  new  areas  of  mathematics 
are  unfamiliar  and  can  appear  hostile  without  careful  selection  of  notation.  In  addition  the 
further  concentration  of  effort  and  analysis  on  the  early  stages  of  the  lifecycle  will  make  it  more 
difficult  to  Identify  staged  development  mileetones  In  a  large  project. 

It  was  considered  essential  to  progress  the  formal  methods  work  by  attempting  to  quantify  the 
relative  weights  of  these  potential  costs  and  benefits  under  project  conditions.  A  pilot  project 
has  been  Identified  and  trill  be  undertaken  over  the  second  half  of  1988  at  BAe  Warton.  This  will 
include  Che  education  and  training  of  software  and  systems  engineers  prior  to  their  Involvement  In 
a  heavily  'Instrumented*  but  otherwise  realistic  project.  The  project  trill  rely  on  a  well  defined 
FORMAL  CORE  method,  In-house  and  external  training  courses  and  Z  editing,  printing  and  database 
tools  Integrated  with  Che  CORE  workstation.  This  project  will  establish,  quantitatively  where 
possible,  indicative  costs  and  benefits  of  using  formal  methods  In  a  realistic,  avionic  project 
envlronsMnt. 

REFERENCES 

1)  C.  P.  Price  and  D.  Y.  Forsyth,  British  Aerospace,  'Practical  considerations  in  the 

Introduction  of  requirements  analysis  techniques',  1982,  'Software  for  Avionics  -  Advisory 
Group  on  Aeronautical  Research  and  Development  -  Proceedings  330'. 

2)  P.  Cronshaw,  British  Aerospace,  'The  Experimental  Aircraft  Programme  software  toolset’,  1966, 
Software  Engineering  Journal  Novei^er. 

3)  A.  0.  Ward,  British  Aerospace,  'Three  generations  of  software  engineering  for  airborne 

systems',  1988,  Paper  21  of  theee  proceedings. 

4)  'The  Official  Handbook  of  Mascot,  Version  3.1,  Issue  I*  •  Published  by  the  Joint  lECCA  and 
MUF  Committee  (JIMCOM),  Royal  Signals  and  Radar  Establishment,  Malvern,  England. 

5)  G.P.  Kullary,  'CORE  •  a  method  for  controlled  requirements  specification',  Proceedings  of  4th 
International  Conference  on  Software  Engineering,  IEEE  Computer  Society  Press. 

6)  N.  Looney,  'CORE-STARTS  Debrief  Report',  1986,  Published  by  National  Computing  Centre, 

Manchester,  England. 

7)  C.  B.  Jones,  'SystecoMtle  Software  Development  using  VDN',  Prentice  Rail  International  Series 
In  Computer  Science,  1986. 

8)  1.  Hayes,  'Specification  Case  Studies',  Prentice  Hall  International  Series  in  Computer 

Science,  1987. 

ACKMOWLEDGPCWTS 

I  would  like  to  thank  the  Directors  of  British  Aerospace,  Military  Aircraft  Division  for  their 
permission  to  publish  the  paper. 

I  would  also  like  to  acknowledge  the  support  of  the  Procurement  Executive  of  the  Ministry  of 
Defence, 


SCHEMA 


Hgime  Basle  ForiMl  of  Mods!  BMsd  PonMl 

n  I  la  II  1  ■!  II  ■ 

apoCfiiGOOon  ■smoos 


FIgun  7  A  Z  Sdwira 

DISCUSSION 


K.BeniMr,  US 

Is  there  automated  support  for  establishing  and  maintaining  “threads"  between  Requirements  and  Specifications,  in 
particular,  one-to-many  relations? 

Author’s  Reply 

In  the  core  viewpoint  hierarchy,  the  threads  of  a  “requirements”  viewpoint  must  be  fulfilled  by  the  combined  threads  of 
the  constituent  “specification"  viewpoints  —  the  relationship  is  one-to-many.  The  core  automated  support  ensures  that 
the  interface  of  “requirements"  viewpoint  threads  to  their  environment  (i.e.,  other  viewpoints  at  the  requirements  level) 
and  is  maintained  at  the  specification  level. 

WJVfansel,  Ge 

How  does  Z  relate  to  using  a  formal  method  of  mapping  a  core  requirement  specification  into  a  basic  design  in 
MASCOT? 

Author’s  Reply 

The  strong  mapping  between  core  requirements/specifications  and  MASCOT  design  entities  was  developed  and 
exploited  successfully  on  the  E  AP  project.  The  proposed  use  of  Z  with  core  does  not  afreet  (and  is  complementary  to) 
this  mapping.  Z  is  used  for  the  function  specification  of  threads  within  core. 


M.Stoll,  Fr 

Are  you  using  or  developing  any  tools  that  map  formal  language  into  natural  language? 

Author’s  Reply 

As  part  of  our  integration  of  Z  into  core  for  use  by  systems  engineers,  we  have  attempted  to  formally  define  “language” 
elements  which  are  natural  to  the  domain  of  avionics  control  systems.  The  systems  engineer  uses  these  pre-defined 
elements  in  constructing  a  specification.  No  work  has  been  performed  at  BAe  on  autorruttically  translating  formal 
specifications  into  natural  language. 
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SUflllARY 

The  approaches  taken  to  the  specification  foe  requiteaents  and  design  of 
real-tiae  eabedded  systeas  software  range  froa  *not  at  all*  to  Inforaal  textual 
specifications  to  seai-foraal  graphics-based  languages  for  data  flow,  control 
flow,  state  transition,  data  structure,  etc.,  diagraas  to  foraal  approaches  such 
as  VDM  and  HOS.  Bach  approach  has  soae  probleas  when  applied  to  the 
specification  of  large  software  systeas.  Part  of  the  reason  is  that  there  are 
few  foraally  defined  aodels  of  the  specification  hierarchy  coaaonly  associated 
with  requireaents,  design,  and  iapleaentation  specifications.  Such  a  aodel  is 
required  as  a  point  of  reference  in  discussions  about  such  specification  issues 
and  coapleteness  and  consistency  analysis  perforaed  by  soae  of  the  current 
generation  CASE  tools.  A  aodel  can  provide  guidance  in  the  identification  of 
just  what  inforaation  to  specify;  regardless  of  the  syntactic  aspects  of  the 
specification  approach  used  to  capture  this  seaantlc  inforaation.  In  addition, 
such  a  aodel  can  be  applied  as  a  the  deductive  interence  aodel  underlying  an 
Al-assisted  CASE  environaent  capable  of  exercising  a  greater  "experts* 
understanding  of  the  inforaation  being  specified  that  current  generation  C^SE 
tools . 

This  paper  presents  such  a  aodel  in  the  fora  of  a  theory  of  Real-tiae 
Eabedded  Systea  Specification,  RESS  theory.  A  partial  vocabulary  of  theory  is 
presented  along  with  the  basic  axloas  and  representative  theoreas. 

Introduction 

The  intent  of  this  paper  is  to  present  an  introduction  to  a  theory  which 
will  hopefully  contribute  to  the  understanding  of  the  various  aspects  and  levels 
involved  with  the  specification  of  software  based  systeas.  In  addition,  a 
fraaework  for  the  definition  of  consistency,  coapleteness,  and  correctness  for  a 
given  set  of  software  specifications  is  developed. 

The  nuaber  of  different  classes  of  inforaation  required  to  coapletely 
describe  a  given  software  systea  leads  to  a  theory  both  broad  in  scope  and  deep 
in  coaplexity.  A  theory  of  specification  Bust  place  all  of  these  classes  in  a 
general  fraaework  and  provide  a  aeaningful  interpretation  of  these  classes  and 
their  interrelationships.  To  facilitate  the  application  of  such  a  theory,  the 
theory  aust  be  described  using  a  language  as  close  to  the  language  of  the 
application  doaain  as  possible  while  still  retaining  the  foraal  seaantics 
required  for  precise  description.  This  paper  discusses  the  need  for  such  a 
theory,  presents  soae  of  the  theory’s  basic  definitions,  and  provides  an 
overview  of  its  coaplete  scope,  it  also  describes  a  potential  application  of  the 
theory  and  discusses  how  the  theory  aay  be  useful  in  day-to-day  software 
developaent  for  real-tiae  eabedded  systeas. 

A  second  title  to  this  paper  could  have  been,  *Th»  Tao  of  Software 
Specifications”.  The  Theory  of  Real-Tiae  Eabedded  Systea  Specifications,  RESS 
theory,  is  based  on  the  interplay  between  two  opposing,  in  a  yin-yang  like 
fashion,  concepts;  that  of  the  syntactic  and  the  seaantic  nature  of  inforaation 
aanipulation.  When  identifying  and  specifying  a  requirement  or  design,  the 
syntax,  ie.,  the  representational  and  structural  constraints  governing 
associated  data  and  transforaation  objects,  as  well  as  the  seaantics,  ie.,  the 
inforaation  content  of  these  data  objects  and  transforaations,  are  equally 
iaportant.  This  duality  provides  a  unique  and  analysable  noint  of  view  of  the 
problea  and  peraits  a  useful  separation  of  specification  concerns,  in  turn,  this 
leads  to  a  view  of  consistency  and  coapleteness  which  is  aore  robust  than  that 
which  is  generally  applied  to  the  analysis  of  real-tiae  specifications.  By 
realising  and  properly  focusing  on  the  natural  interplay  between  these  two 
aspects,  a  view  of  specifications  can  be  developed  which  is,  in  a  Taoist  sense, 
in  balance  and  haraony. 

This  paper  does  not  propose  any  specific  language  or  foraat  for  the 
representation  of  software  specifications.  There  are  already  aany  such  foraats 
to  choose  froa.  Such  standards  as  the  DOD*s  2167,  the  FAA’s  DO-178A,  Boeing's 
06-35071,  languages  like  PSL/P8A  and  AXES  of  the  HOS  aethodology,  and 
aethodologies  as  Structured  Analysis  -  Structured  Design  all  propose  soae  aeans 
of  requireaents  and/or  design  representation.  Soae  of  these  approaches;  PSL/PSA, 
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Structured  Analysis  -  Structured  Ziesi^n;  are  priaarlly  foraat  standards.  In 
other  words, 

if  one  has  a  given  set  of  infornation  to  capture  in  a  specification  then  it 
should  be  specified  in  such  and  such  Banner. 


Others  are  Information  content  standards;  DoD's  2167,  Boeing's  D6-35071; 

one  should  specify  the  following  classes  of  information  in  some  acceptabl' 
hierarchically-organized  manner  once  they  have  been  identified  and 
collected. 


Some  of  the  current  approaches  to  software  specification  base  their 
representation  language  and/or  formats  on  a  formal  semantic  definitions.  For 
example,  HOS  bases  its  requirement  specification  syntax  on  a  set  of 
algebraically  defined  constructs,  a  language  called  AXES,  which  may  be  used  to 
decompose  high  level  functions  into  lower  level  functions  in  a  correctness 
preserving  fashion.  The  lower  level  functions  are  either  additional  sub¬ 
functions,  also  specified  using  AXES  constructs,  or  are  primitives  with  obvious 
or  axiomatically  characterizable  properties  [1).  The  decomposition  process 
continues  until  a  level  of  abstraction  is  reached  where  the  correctness  of  the 
execution  of  sequences  of  operations  appears  to  be  obvious.  Thus,  the  semantic 
properties  of  a  given  program  specified  using  the  approach  of  ROS  are  defined 
"operationally"  [2].  One  drawback  to  this  approach  is  the  difficulty  in  querying 
the  specification  on  a  detailed  requirement.  For  example,  if  one  wants  to 
determine  from  the  specification  what  the  program  is  required  to  generate  for  : 

output  Z  in  sub-mode  "a*  of  mode  "A"  when  the  input  X  is  0 

One  must,  in  essence,  "symbolically"  execute  the  specification  until  the  above 
situation  is  uncovered  and  the  answer  is  apparent.  It  is  not  easy  to  go  and  look 
up  Z  and  find  out  its  relation  to  input  X  in  mode  A. 

Other  approaches  to  requirement  specification  follow  a  more  traditional 
intuitive  and  pragmatic  paradigm  proposing  standard  templates  for  expressing 
common  specification  classes.  These  are  usually  based  on  experience  developing 
software  according  to  the  "just  start  coding  it  up  and  then  debug  it  into 
correctness"  (31  school  of  thought.  PSL/PSA  proposes  the  specification  of  a 
system  in  terms  of  the  Entity-Attribute-Relationship  model  of  the  desired 
system.  The  Problem  Statement  Language  is  a  restricted  set  of  relationships 
useful  in  describing  desired  relationships  between  input,  process,  and  output 
objects  of  the  system  being  specified.  The  Problem  Statement  Analyzer  acts  like 
a  relational  database  manager  over  the  possible  relations  described  via  PSL 
providing  a  query  mechanism  for  retrieval  of  the  information  specified  in  this 
manner.  PSL/PSA  is  an  example  of  a  methodology  independent  facility,  ie.  there 
is  no  formal  definition  of  consistency  or  completeness  properties  of  the 
resultant  specification.  (4). 

Still  other  more  formally  based  approaches  have  tended  to  leave 
"requirement"  specification  to  representation  in  informal  textual  prose,  if  at 
all.  They  proceed  to  axiomatically  characterize  the  desired  semantic  properties 
of  specific  programming  language  "implementation”  expressions.  Such 
specifications  often  take  the  form  of  Hoare-logics 


expressions.  In  this  case  P  is  a  precondition  assertion  describing  the  condition 
of  the  input  state  space  which  must  hold  before  execution  of  the  process  Q  in 
order  for  the  execution  of  Q  to  guarantee  that  upon  termination  the 
postcondition  R  will  hold  over  the  output  state  space.  An  examples  of  such  an 
approach  can  be  found  in  (51.  The  methodology  described  was  derived  from  a 
methodology,  HELLNADE  (6),  developed  in  an  experiment  in  formal  software 
development  methodologies  at  Honeywell.  This  method  proposed  the  specification 
of  a  system's  design  using  <P,  R>  tuples  describing  the  desired  properties  of  a 
hierarchically  organized  abstract  machines.  Dijk8tra''6  constructive  approach, 
ie.  the  application  of  his  "wp"  predicate  transformer  ^n  the  derivation  of  a 
program's  sequential  operator  sequences  from  the  program's  <P,  R>  tuple,  was 
applied  to  assist  in  the  determination  of  a  "provably  correct"  next  lower  level 
of  abstract  machines. 

Tool  vendors  supplying  Computer-Aided  Software  Engineering  (CASE)  products 
often  sit  between  the  mathematically  formal  and  the  pragmatically  informal.  Most 
CASE  tools  support  specification  techniques  which  have,  or  could  have,  a  formal 
semantics.  However,  the  vendors  often  advertise  that  their  tool  provides 
"methodology  independent"  representational  techniques.  They  suggest  that  users 
supply  their  own  semantic  interpretations  of  the  tools  graphics  and/or 
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languages.  The  tools  aeldoe  enforce  any  particular  aeeantica  within  the  CASE 
tool  other  than  the  "syntactical"  semantics  of  the  representational  techniques 
being  supplied.  An  example  would  be  the  level  balancing  of  dataflow  diagramming 
tools. 

Prom  a  business  perspective  this  may  be  necessary.  Software  developers  on 
the  whole  are  very  particular  in  the  area  of  methodology  preferences.  A  tool 
which  rigorously  enforces  a  specific  semantics#  and  thus#  methodology,  often  has 
trouble  selling  to  the  general  development  community. 


irhy  a  Formal  Theory  of  Specification  7 

One  of  the  prime  reasons  for  mathematical  formality  in  specifications  is 
that  human  languages  are  notoriously  full  of  ambiguities,  double  meanings, 
context-dependencies,  and  other  such  characteristics.  The  written  forms  of  such 
languages  do  not  have  complete,  and  commonly  agreed  upon,  syntactic  and  semantic 
characterisations.  Such  characterisations  enable  each  expression  of  the  formally 
defined  language  to  carry  exactly  and  only  the  Information  required  for  correct 
interpretation. 

The  strength  of  human  languages  is  that  they  can  convey  a  great  deal  of 
information  with  very  little  actual  expression  by  counting  on  the  receiver  of 
the  expression  to  complete  the  information  transfer  from  his  or  her  experience 
and/or  context.  The  weakness  of  human  languages,  at  least  for  the  conveyance  of 
precise  information,  is  that  each  individual's  experience  or  context  differs; 
often  in  very  subtle  ways.  The  requirement  expressions  : 

"The  value  of  the  output  shall  be  computed  sufficiently  often  enough  to 
prevent  undue  ...” 

"The  user  interface  shall  be  easy  to  learn..." 

"Response  to  changes  in  input  value  shall  be  fast  enough  to  minimise  the  lag 
time  through  the  system." 

which  are  of  little  worth  to  the  designer  of  a  software  system,  are  also  3  of 
the  most  often  written  software  requirement  expression  schemas. 

The  reader  of  a  traditional  textual  requirements  specification  brings  a 
different  interpretation  context  to  the  specification  than  does  the  writer.  This 
invariably  leads  to  interpretations  of  the  specification  which  differ  by  some 
unknown  degree.  This  results  in  a  potential  for  errors  during  design  which  ate 
very  subtle  and  difficult  to  detect;  both  the  writer  and  reader  think  they  are 
in  agreement,  not  realising  they  are  interpreting  the  same  sentence  differently. 


Currently  popular  CASE  tools  can  compound  the  problem  of  detection  of 
differences.  The  major  focus  of  the  graphics-oriented  tools  and  methods  has  been 
the  syntactic  aspects  of  their  associated  languages. 

.  Their  syntaxes  are  normally  well  defined. 

Consistency  and  completeness  of  such  specifications  are  defined  in 
syntactic  terms  like  level  balancing  and  parse-ability. 

Syntax-directed  tools  support  the  representation  and  analysis  of 
requirements  specified  by  applying  them. 

This  focus  often  results  in  syntactically  complete  and  consistent 
specifications. 

However,  many  proponents  of  such  approaches  associate  semantic  correctness 
with  such  attributes.  This  is  generally  an  invalid  inference.  The  information 
content  of  syntactically  well-formed  specifications  may  not  be  semantically 
complete  and  consistent  with  respect  to  the  problem  Itself,  or  even  other  parts 
of  the  same  specification.  This  results  from  the  lack  of  a  well-defined  and 
well-supported  axiomatic,  denotational,  or  even  operational,  semantics  for  the 
languages  on  which  the  graphic  approaches  are  based. 

Engineers  communicating  via  textual  specifications  are  usually  familiar 
with  the  problems  of  Interpretation  and  are  thus,  generally  on  guard  for  such 
occurrences.  However,  when  communicating  via  real-time' extended  dataflow 
diagrams  {7],  for  example,  they  often  believe  that  since  the  graphic  languages 
have  relatively  formal  syntactic  definitions  they  also  have  a  commonly  agreed 
upon  formal  semantics.  Thus,  they  are  not  on  guard  and  often  miss  occasions  of 
differences  in  semantic  interpretation. 

In  addition,  most  CASE  tools  providing  such  graphic  representation 
techniques  are  said  to  be  capable  of  automatically  checking  specifications  for 
consistency,  completeness,  and  correctness.  For  conmercially  available 
structured  analysis  and  structured  design  tools,  such  checking  is  invariably 
syntactic  in  nature.  They  do  not  have  the  capacity  for  representing  the  semantic 
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properties  of  the  specification,  let  alone  analysing  the  senantics.  For  example, 
they  can  detect  an  error  in  a  specification  calling  for  the  generation  of  a 
data  object  "out  of  thin  air",  ie.,  from  no  specified  set  of  inputs. 


VBRTICAL  VELOCITY 
- > 


But  they  can  not  detect  an  error  in  a  specification  of  the  generation  of  a  data 
object  required  to  represent  "vertical  velocity*  from  data  objects  representing 
"horisontal  distance*  and  "time’^T 


HORIZONTAL  DISTANCE 


VBRTICAL  VELOCITY 


One  of  the  reasons  for  this  deficiency  is  a  lack  of  support  for  expression 
of  data  type^  le.,  the  full  set  of  syntactic  properties  of  a  give  data  object 
plus  the  range,  dimensionality,  and  possible  nanipulaticns  of  the  values  which 
may  be  bound  to  the  object.  Host  only  permit  a  rudimentary  form  of  data  object 
structuring  in  the  form  of  traditional  data  dictionary  entries. 

An  automated  syntactic  analysis  capability,  when  coupled  with  the  belief 
that  the  techniques  do  have  a  commonly  agreed  upon  semantics  among  engineers 
following  a  common  methodology,  often  leads  users  into  a  very  false  sense  of 
security.  This  allows  problems  to  propagate  all  the  way  to  design  or 
implementation  before  they  are  detected  and  dealt  with. 

Formal  specification  approaches  suffer  from  a  different  class  of  problems. 
They  do  not  suffer  from  problems  in  Interpretability  so  much  as  manageability. 
Once  an  engineer  learns  the  formal  language  of  discourse,  for  example,  first 
order  predicate  calculus,  such  specifications  are  no  more  difficult  to  interpret 
than  any  other  formal  language,  such  as  a  high  level  programming  language, 
instead,  an  often  expressed  opinion  is  that  the  drawbacks  to  the  application  of 
most  formal  methods  are  related  to  the  fact  the  method  was  originally  created 
for  "toy*  academic  problems.  Such  methods  are  often  difficult  to  scale  upward  to 
handle  large  problems. 

The  semantics  of  a  single  source  code  procedure  may  be  specified  in  the 
pre-  and  postconditional  assertions  of  axiomatic  approaches  to  specification 
(8].  This,  in  ay  opinion,  is  not  all  that  difficult.  But  the  mental  and  physical 
manipulation  of  all  the  terms  in  the  expression  of  the  postcondition  for  an 
entire  embedded  system,  without  support  of  automated  tools,  is  considered  by 
even  the  most  diligent  and  mathematically  inclined  to  be  extremely  difficult  and 
tedious,  at  best. 

A  postcondition,  the  logical  assertion  describing  a  relationship  to  be 
maintained  between  a  system's  input  and  output  state  space,  will  contain,  as  a 
bare  minimum,  as  many  AND'ed  terms  as  there  are  system  output  objects. 

In  practice,  a  system  describable  in  such  a  minimum  fashion  would  only  be 
capable  of  minimal  functionality.  Such  a  postcondition  would  also  require 
pairing  with  a  very  strong  precondition.  Such  a  precondition  would  necessarily 
express  the  requirement  that  the  input  state  space  be  guaranteed  to  never  exist 
in  a  state  indicating  missing  or  corrupted  data.  In  other  words,  an  input  state 
space  in  which  all  input  objects  are  bound  to  values  directly  usable  in  the 
semantic  transformations  which  satisfy  the  single  term  postcondition  of  the 
associated  output  object.  For  embedded  systems,  such  a  guarantee  is  generally 
impossible . 

Thus,  much  of  the  software  for  an  embedded  system  is  geared  toward  adding 
exception  handling  capability  minimising  the  strength  of  the  precondition  such 
that  for  any  point  in  the  input  state  space  a  valid  output  response  is  given. 
This  strengthens  the  ability  of  the  embedded  system  to  deal  with  loss  or 
corruption  of  its  input  data  and  minimises  its  dependents  on  its  parent  system. 

In  addition,  most  typical  software-based  embedded  systems  are  software- 
based  because  of  a  requirement  to  support  multiple  modes  of  operation.  Also 
because  of  the  ease  in  which  software  ca.n  be  designed  to  manage  such  changes  in 
operational  state,  in  such  an  embedded  system,  some  number  of  the  output  objects 
can  be  expected  to  have  differen^  terms  relating  to  its  semantics  in  the 
postcondition  for  each  mode,  as  well  as  different  exception  handling  terms. 
Thus,  the  number  of  terms  in  the  postcondition  of  rtven  a  simple  embedded  system 


is  probably  at  least  an  order  of  Magnitude  greater  than  the  number  of  output 
objects.  Also,  this  Is  only  at  the  Most  abstract  level  of  specification.  As  the 
software  design  is  laid  out,  decomposing  the  problem  into  lower  level 
subsystems,  the  number  of  postconditional  terns  expands  exponentially. 

A  methodology  for  partitioning,  manipulating,  and  managing  the  massive 
amount  formal  expression  must  be  developed.  Without  such  a  methodology,  the 
formal  development  of  meaningful  embedded  systems  becomes  intractable  and 
essentially  impossible.  Another  drawback  to  formal  specification  is  that  it 
calls  for  greater  precision  of  information  than  informal  specifications. 

A  methodology  for  formal  specification  must  also  assists  in  the  initial 
identification  of  just  what  information  to  specify  in  order  to  support  such 
precision.  Precisely  what  set  of  information  completely  captures  the 
requirements  of  a  given  problem,  and  what  properties  must  be  true  for  elements 
of  this  set  to  be  considered  semantically  consistent,  are  questions  not  well 
addressed  by  the  currently  supported  languages,  tools,  and  methodologies. 

There  is  also  little  academic  work  on  these  aspects  of  real-time  software 
requirements  specification  to  turn  to.  Most  of  the  work  considering  semantic,  as 
well  as  syntactic,  properties  do  so  only  at  the  program  source  code  level.  [9, 
10,  11].  Other  work  in  theories  of  specification  ignore  the  application  world's 
perspective  on  the  problem  staying  very  academic  and  closely  related  to 
academically-nice,  but  fictional,  programming  languages  like  Dijkstra's  guarded 
commands.  112].  No  work  that  I  am  aware  of  discusses  the  special  attributes  and 
constraints  of  formal  specifications  for  real-time  embedded  systems.  Nor  is 
there  any  work  formally  treating  the  real-time  embedded  system  concepts  of 
program  design,  when  formal  specifications  approaches  are  discussed  at  all  it  is 
with  respect  to  a  "logically  correct"  program  rather  than  an  "efficient", 
"modifiable",  "understandable",  etc.  program. 

In  order  to  define  such  a  methodology,  one  must  have  a  theory  describing 
the  objects  to  be  manipulated  by  the  methodology  and  the  relationships  between 
those  objects  which  provides  the  basis  of  the  legal  manipulations  which  nay  be 
carried  out  within  the  methodology.  The  purpose  of  RBSS  theory  is  to  provide  a 
model  from  which  a  formal  development  methodology  may  be  developed,  it  also 
provides  a  basis  for  the  mathematical  proof  of  the  specification  properties; 
completeness,  consistency,  and  correctness;  for  all  and/or  between  all  abstract 
specification  levels. 

In  general,  a  theory  consists  of  a  language  and  a  set  of  axioms  or  axiom 
schemas.  The  language  used  in  such  a  description  is  the  language  of  predicate 
logic  where  the  set  of  constant,  function,  and  predicate  symbols  are  restricted 
to  a  specific  vocabulaty,  i«.,  a  pafticulai  subset  of  the  symbols  allowed  in 
general  predicate  logic.  Each  of  the  subsets  in  the  vocabulary  nay  be  finite  or 
infinite,  empty  or  non-empty.  The  terms,  sentences,  and  expressions  of  a  theory 
are  those  terms,  sentences,  and  expressions  of  predicate  logic  whose  constant, 
function,  and  predicate  symbols  are  in  the  vocabulary  of  the  theory.  (12]. 

This  paper  is  not  intended  as  a  complete  and  detailed  mathematical 
treatment  of  RESS  theory.  Instead,  it  presents  an  interrelated  set  of  ideas 
which  can  offer  many  practical  software  specification  guidelines  while  providing 
an  overview  of  its  scope  and  purpose. 

The  presentation  of  RESS  theory  follows  in  spirit,  if  not  complete 
mathematical  rigor,  the  general  axiomatic  approach  to  theory  presentation  by 
introducing  n  subset  of  its  terms,  definitions,  and  logical  operators.  This 
semi-formal  approach  will  facilitate  the  presentation  of  the  theory  and  the 
expression  of  axioms  and  theorem  characterizing  attributes  of  the  theory  and  its 
application  while  permitting  enough  abstraction  of  in  the  language  of 
presentatiOii  to  describe  the  theory  in  terms  of  real-world  concepts  like  "data 
object",  "Function",  "Architectural  Design",  etc. 

In  essence,  RESS  theory  defines  a  set  of  valid  relationships  among 

1.  an  abstraction  level  of  requirement  specifications, 

2.  a  valid  satisfaction  of  functional  requirements  by  a  functional  design 
specified  in  terms  of  sequences  of  canonical  data  transformations, 

3.  a  "fuzzy"-sati8faction  of  Non-Functional  requirements  (memory 
constraints,  processor  throughput  limitations,  maintainability,  hardware 
organization,  etc.)  in  terms  of  architectural  design  sped fications  .that 
generalize  and  subsume  the  canonical  data  transformation  sequences, 

4.  and  the  requirement  specifications  for  the  next  lower  level  of 
abstraction. 

In  sequence,  the  rest  of  this  paper  introduces  definitions  for  some  of  the 
terms  and  logical  operators  comprising  the  vocabulary  of  BBSS  theory.  It  then 
presents  an  informal  expression  of  some  of  the  primary  axioms  and  theorems  of 
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RBSS  theory.  Finally,  it  diacuases  the  application  of  RBSS  theory  as  a  basis  for 
an  Al-based  software  specification  assistant. 


Vocabulary  of  RBSS  Theory 

RBSS  theory  describes  the  contents  of  and  relationships  aaong  eleaents  in 
the  set  of  software  specification  classes.  In  order  to  state  tne  axions, 
theoreas.  and  rules  of  RBSS  theory,  these  eleaents  aust  be  given  accurate  and 
consistent  definitions.  It  is  not  intended  that  the  definitions  given  are  the 
only  true  definitions  for  such  teras;  only  that  they  are  consistent  ones. 


Definition  :  Data  Object  Dl 

An  inforaation  carrying  eleaent  having  a  specific  syntactic  representation, 
or  data  structure,  and  a  specific  application  doaain  seaantics,  ie.,  its 
value  binding,  potential  range  of  value  bindings,  and  diaensionality .  For 
this  paper  data  objects  will  either  have  aeaningful  naaes  or  be  represented 
by  lower  case  letters  u.v.w.x.y.  and  s. 


In  order  to  refer  to  the  syntactic  and  semantic  attributes  of  a  given 
specification  eleaent  or  class,  RESS  theory  defines  two  unary  operators,  5r() 
and  sv(),  which  reference  the  syntactic  representation  and  semantic  value 
aspects  of  their  single  parameters,  respectively. 

Definition  :  Syntactic  Representation  Operator  D2 

The  Syntactic  Representation  Operator,  sr(),  is  a  unary  operator  that  returns 
the  syntactic  structure  of  its  operand. 

For  example  : 

sr( velocity_object)  -  "REAL  +/-  10“^" 

Or 

sr(set_of_velocity_^objects)  -  "Array  f0..25]  of 

REAL  +/-  10"®" 

When  the  operand  is  a  data  object,  the  srl )  operator  may  be  looked  at  as 
returning  all  the  inforaation  normally  associated  with  the  concept  "data  type" 
without  reference  to  its  valid  range  of  values,  its  access  methods,  or  any 
dimensionality.  The  operand  of  an  sr()  need  not  be  a  data  object  but  can  be  any 
object  with  a  syntactic  attribute. 

Definition  :  Semantic  Value  Operator  D3 

A  Seaantic  Value  Operator,  $v(),  is  a  unary  operator  which  returns,  or 
represents,  the  semantic  value  of  its  operand. 

For  example  : 

sv( velocity^object)  •  "100  kph  e  (0  kph  ...  500  kph}" 

A  very  important  point  to  notice  is  that  the  units  "kph"  and  the  potential 
range  of  values  "{0  kph  ...  500  kph)"  is  as  much  a  part  of  the  semantic  value 

of  the  object  as  the  "100".  Also,  the  operand  of  an  5v( )  need  not  be  a  data 
object  but  may  be  any  object  that  has  an  intended  meaning  associated  with  it  not 
expressed  by  its  structural  representation. 

Groups  of  data  objects  present  at  the  input  and  output  boundaries  of  a 
system;  software,  hardware,  or  abstract;  and  their  interrelationships  form  the 
doaain  of  discourse  for  Requirement  Specification  for  that  system.  It  is  a  well 
accepted  view  that  requirements  express  "what"  a  system  is  supposed  to  do  to  the 
data  objects  at  its  input  boundary  in  order  to  generate  those  data  objects 
expected  at  its  output  boundary.  However,  very  often  requirements  are  specified 
using  an  operational  language  which  makes  statements  about  the  process,  the 
"how",  of  performing  the  required  transformations.  For  example: 


Let  x,y  be  input  objects 
z  be  a  output  object 


IF  the  inputs  x  and  y  have  had  SO  ms  to  settle 
THEN  z  should  be  set  to  x  ^  y 
ELSE  z  should  be  reset  to  0 


RBSS  theory  defines  a  requirement  to  be  a  relationship  between  a  data 
object  required  to  exist  at  the  system's  output  boundary  at  a  specific  point  in 
time  and  some  subset  of  the  data  objects  at  the  system's  input  boundary  from 
which  the  output  object  is  derivable. 


(z  •  X  *  y)  §Time  ((t  •  Tq  +  50  ms)  A  (y  #  0)) 
V 

z  <■  0 


In  the  first  approach  the  requirement  expression  implies  a  sequence  of 
processing  that  is  an  unnecessary  over-specification.  This  often  prejudices  the 
designer.  In  addition,  the  process-oriented  view  of  the  first  example  does  not 
promote  the  mathematical  reality,  not  just  the  implementation  reality,  that  z 
cannot  be  set  to  x  -f  y  if  y  •  0.  Also,  the  first  example  leads  one  to  expect 
that  z  must  be  set  to  0  on  every  examination  prior  to  50  ms.  This  need  not  be 
the  case  if  z  can  be  shown  to  have  been  initialized  to  0  at  and  is  not 
affected  by  any  other  requirement. 

In  order  to  facilitate  the  description  of  such  relationships,  RESS  theory 
incorporates  the  concept  of  "state  space". 


Definition  :  State  Space  D4 

A  Cartesian  space  whose  dimensions  (not  to  be  confused  with  object  value 
dimensionality,  .ie,  "kilometers  per  hour")  are  defined  by  a  set  of  data 
objects.  The  scale  for  each  dimension  is  defined  by  the  valid  range  and 
precision  of  the  value  of  each  data  object. 

Thus  a  state  space  consisting  of  two  data  objects  x,y  of  type  integer  with 
range  -10  to  10  with  precision  of  2  would  define  a  state  space  like  the 
following  : 


Y 


If  X  and  y  are  the  only  inputs  to  a  system  then  each  point  of  the  above 
grid  represents  a  possible  state  of  the  input  state  space  and  which  the  system 
is  required  to  deal  with  appropriately. 

For  this  paper,  an  input  state  space,  consisting  of  all  the  input  data 
objects  of  a  given  system  and  the  vector  describing  the  set  of  values  which  make 
up  the  current  state  represented  by  a  specific  point  in  the  state  space,  is 
referred  to  by  "I".  A  system  output  state  space  and  vector  is  referred  to  by 
"0".  When  describing  relationships  involving  only  a  single  output  object,  which 
may  consist  of  more  primitive  objects  but  is  identifiable  in  its  own  right,  the 
designation  is  used  with  the  understanding  that 

Vi:  Oj  c  0. 

Ij[  refers  to  the  set  of  all  partial  input  state  spaces  on  which  depends,  when 
referring  to  the  j'th  partial  input  state  space  on  which  0^  depends  in  a  given 
circumstance,  I^j  is  used  with 

V  i,j  :  lij  c  c  I. 

In  addition,  for  any  state  space  X  : 

8r(X)  •  the  Cartesian  space  defined  by  ail  data  objects  in  x 
multiplied  by  their  ranges. 

sv(x)  •  a  specific  point  in  sr(X)  identified  by  the  vector 
made,  up  from  the  current  values  of  all  the  data 
objects  making  up  X. 


The  concept  of  state  space  provides  a  means  by  which  a  definition  jf 
"abstraction  level"  may  be  given. 
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Oefir.ltion  :  Specification  Abstraction  Level  D5 

RESS  theory  defines  Specification  Abstraction  Level  to  be  the  view  of  a 
software  system  through  the  information  present  in  the  syntactic  structure 
and  semantic  value  associated  with  a  given  input/output  state  space  tuple 
<I ,0> . 


Within  BBSS  theory,  any  and  all  information,  including  requirement 
specifications  and  design  specifications,  that  involve  relations  among  those 
data  objects  making  up  a  given  <I,0>,  is  defined  as  pertaining  to  the  same 
Specification  Abstraction  Level.  This  view  of  abstraction  is  a  projection  on  the 
hierarchical  structure  of  a  software  system  in  general.  It  is  not  the  same 
definition  of  abstraction  associated  with  "data  abstraction”  and  "abstract  data 
types" . 

Many  of  the  relations  defined  in  this  paper  reference  a  state  of  o  given 
state  space  as  a  parameter,  in  order  to  facilitate  the  application  of  these 
relations  in  examples  where  the  data  objects  have  been  individually  enumerated, 
a  state  constructor  is  all  be  defined. 


Definition  :  State  Space  Constructor  D6 

A  State  Space  Constructor  is  an  operator  that  takes  a  list  of  individual  data 
objects  and  denotes  the  current  state  and  state  space  which  results  from 
their  valid  ranges  taken  together. 

yj^,  y2,  ...  y^  be  a  list  of  data  objects 

Then  n  y^  denotes  their  cartesian  state  space 

^i.l...n  Vi  •  I 

<-> 

*^i-l.  .  .n  Vi^  " 

A 


in  RESS  theory,  the  definition  of  the  term  "function"  is  closer  to  its 
mathematical  form  rather  than  the  software-traditional  definition  of  "a  process 
to  be  performed". 


Definition  i  Function  D7 

A  Function,  /(),  is  mapping  relationship  between  a  point  in  the  function  i 
domain,  the  function's  input  state  space  vector  I,  and  some  point  In  its 
codomain,  its  output  state  space  vector  0. 

O  -  /(I) 

or 

<sr(0),sv(0)>  -  /(  <sr(l),sv(l)>  ) 


RESS  theory  makes  use  of  the  mathematical  definition  of  function  in  order 
to  define  the  requirement  specification  concept  of  Functional  Assertion. 

Definition  :  Functional  Assertion  D8 

A  Functional  Assertion,  O;  -  statement  that  at  some  point, 

or  points,  in  time  there  is  reqoirea  to  exist  a  mapping  between  a  valid  point 
in  an  output  state  space,  established  by  the  i'th  output  data  object  of  a 
system,  and  a  valid  point  in  the  state  space  established  by  the  j'th  set  of 
input  objects  from  which  is  derivable.  This  mapping  is  dictated  by  the 
syntactic  representation  and  semantic  value  of  the  object  ,  the  objects 
making  up  l^j,  and  of  /in*  As  a  matter  of  convenience,  the  following 
syntactic  conventions  is  used  : 

sr(0j  -  fijdij))  -  <Iij.  /ij.  0j> 

St(Oi  -  -  Ijj 

st(Oi  -  /ijdij))./  -  /ij 


»t(Oi  - 


u 


-  “i 


A  Functional  Aaaertion  la  a  9anecalixatlon  of  the  sat  of  infocaatlon 
chacactcclaable  by  a  Hoara-logica  expraaaion.  Thua,  tha  aanantlc  value  of  a 
Functional  Aasartlon  la  aqual  to  juat  this  sat  of  Inforaatlon. 


sv(Oi  -  /ij(Iij))  •  sosePd^j)  (  /jj  )  sonsRd^j.Oj) 

In  order  to  fully  specify  a  Functional  Assertion,  all  of  the  Inforaatlon 
required  by  the  seaantlcs  of  such  a  p()  (Q)  R( )  expression  aust  be  Included. 

As  an  exaaple  : 


Let  av(x) 
sr(x)  - 
sv(y)  - 
sr(y)  - 


sv(z)  - 
sr(i)  - 


avl/jj ) 


>  dittanc*  in  "kiloaetars* 

REAL  with  precision  1  X  10'^ 
tiae  in  ”houre:ainute«:seconds* 
tiae_structure  >  record 

hours  :  INTEGER 
ainutes  :  INTEGER 
seconds  :  INTEGER 
end  record 

velocity  in  "kph*  <••  500  kph. 

REAL  with  precision  1  X  10*^ 

•  ”kph  •  "kiloaeters”  ♦  "hours* 

>  positive  REAL  •  positive  REAL  ♦  tlae_structure 


Then 


(av(Oi  -  /tjaij)) 
sv(2  -  ) 

eoaePdjjsOj)  (/ij)  soaeRdjjyO^) 


((0  kiloaeters  •  sv(x))  A  (Br(x)  •  REAL, 

precision  1  X  10"^) 

A 

(0  hours  <  8v(y) ) 

A 

(sr^y)  •  tiae  structure) 

^  ”  y 

(srd)  *  REAL  with  precision  1  X  10'^)) 

i/ij) 

lx’,  y’,  i’,  /jj'  I 

( 8V(/i j ' )  -  SV(/^ j ) ) 

(8V(X' )  •  SV<X) ) 

A 

(8v(y' )  -  8v(y) ) 

A 

(8r(/nd  -  sr(zd  -  8r(x')  sr(y'>) 

A 

(((8v(x')  +'  8v(y')  -  500  kph) 

A 

{8v(s»)  -  sv(xd  8v(yM)) 

V 

(sv(8d  -  500  kph))) 

A 

( sv( z)  -  sv(z* ) ) 

^  y 

(8r(z)  ■  REAL  with  precision  1  X  10'^)] 

A  point  to  note  is  the  introduction  of  x'p  y' »  s',  fij'» 

postcondition.  This  captures  within  the  specification  the  realisation  that  the 
division  iaplied  by  8v(/^j)  does  not  aake  aatheaatical  sense.  The  specification 
of  a  runctional  Assertion-^should  capture  the  fact  that  the  objects  x,  y,  and  s 
are  of  different  8r()'s  and  aust  be  (in  fact  are  required  to  be  due  to  the 
seaantic  properties  of  the  "division”  operator  in  most  strongly  typed  ROL's) 
converted  to  a  coaaon  8r()  prior  to  their  actual  aatheaatical  division.  At  the 
saae  tiae,  it  indicates  the  fact  that  sr(x),  sriy),  and  8r(8),  are  data  types  of 
the  true  input  and  output  objecte  and  that  it  is  an  a-priorl  conclusion  their 


syntactic  representations  are  Inviolate.  However*  the  specification  should  not 
linit  design  freedom  by  stating  what  the  modified  sr()'s  should  actually  be. 

Bach  given  output  object  for  a  real-time  embedded  system  can  be*  and 
generally  is*  the  focus  of  more  than  one  functional  mapping.  BBSS  theory  defines 
a  relationship  between  a  system's  required  functional  mappings  and  "when*  those 
mappings  are  required  to  be  valid  during  the  run-time  operation.  The  attribute 
"when"*  within  the  domain  of  requirement  specifications*  maps  a  Functional 
Assertion  to  the  point(s)  during  run-time  at  which  it  is  relevant  to  the  overall 
specification.  [ 14 ) 

The  manner  by  which  time  is  modeled  is  not  as  important  as  the  need  to 
model  time  using  some  appropriately  defined  temporal  logic.  Indirect  approaches 
to  modeling  real-time  aspects  of  embedded  systems  such  as  those  based  solely  on 
finite  state  transition  specifications*  such  as  the  Control  Flow  model  of 
Hatley-Pirbhai  [15)*  are  inadequate  for  specifying  many  temporal  aspects  of 
BBS's.  It  is  difficult  to  specify  Important  concepts  such  as  "maximum  data 
transport  delay"*  "frequency  of  data  object  transmission**  "maximum  allowable 
time  of  loss  of  input  object  receipt”*  within  such  models;  at  least  within  the 
formal  syntax  of  the  model.  It  is  also  difficult  to  "reason"  about  those 
temporal  aspects  which  they  do  model.  Such  specification  attributes  as  temporal 
consistency  and  temporal  completeness  are  not  defined  for  such  approaches. 

BBSS  theory  generalizes  the  concept  of  finite  state  to  that  of  timepoint 
and  interval  (a  bounded  sequence  of  timepoints).  This  allows  system  "real-time" 
to  be  included  in  the  model  and  defines  a  state  transition  as  either  the  lower- 
bound  or  upper-bound  of  an  interval. 

BBSS  theory  proposes  that  each  Functional  Assertion  must  have  associated 
with  it  a  description  of  "when"  it  is  relevant.  BESS  theory  elevates  this 
temporal  perspective  to  the  level  of  an  axiom*  the  Axiom  of  Temporal  Belevance. 
This  binding  between  a  functional*  or  semantic,  component  of  a  specification  and 
its  associated  temporal*  or  syntactic  (in  the  sense  of  constraints  on  the 
organization  of  the  semantic  properties)  component  is  embodied  within  a 
"Temporal  Belevance  Assertion*. 


Definition  :  Temporal  Belevance  Assertion  d9 

A  Temporal  Relevance  Assertion*  '^ii^^i^/ij^ ^ *  meta-relation 
consisting  of  one  or  more  second  order  sub-assertions  constraining  the  valid 
points  on  the  temporal  axis  of  the  combined  input/output  state  space.  The 
i'th  j'th  Temporal  Belevance  Assertion  defines  the  temporal  conditions 
required  to  exist  in  order  for  the  j'th  Functional  Assertion  producing  output 
object  0^  to  be  considered  a  true  relationship  and*  thus*  relevant  to  the 
overall  specification  of  the  software. 

In  other  words*  a  Temporal  Relevance  Assertion  defines  the  time  points 
during  run-time  at  which  the  specification  of  the  Functional  Assertion  which  is 
its  only  parameter*  is  relevant  to  the  correct  operation  of  the  software  system. 


The  semantic  value  of  a  Temporal  Relevance  Assertion  is  a  set  of  time 
points  at  which  the  Functional  Assertion,  which  is  its  only  parameter*  is  a  true 
relation  between  its  input  and  output  state  space  parameters;  according  to  the 
following  rules  : 

sv(T(...))  "  a  single  time  point  x  :  (0  <•  x] 

or  a  single  set  of  sequential  time  points  x^  a  called  a  well-formed*  wf* 
interval  : 

(0^<-  <  Xp) 

''  ■'i  .  .6  =  I  ■'l.l  <•  ■'B>) 

or  a  wf  set  of  non-sequential  time  points  Tj  : 

W  1,J  :  ((0  <-  Tjl  A  (ti.j)  -->  (Tj  a  Tj))l 
or  a  wf  set  of  wf  intervals  : 

W  l,j  :  MO  <  Tgi) 

((Jai)  ->  -  ((T.^  <-  T.j  <-  Tpj) 

<■'.1  <■  •'BJ  <-  ^Bi>>>> 

or  a  wf  set  of  wf  sets  of  non-sequential  tiue  points  and  wf  intervals. 


► 


Tij(Oi  .  /ijdij)) 

<--> 

Oi  -  •ti»«  rtc  -  0 

or  discrote  ovent; 

TljlOi  -  /ijdlj)) 

< — > 


°i  “  •tl«  50  »ttet  (0(i_i)  - 

or  indirectly  defined  by  a  set  of  changes  in  the  truth  value  of  some  nodal, 
finite-atate-'defining,  predicate; 

Tij(Oi  -  fijdij)) 

< — > 

°1  while  -Ta-.-fi 

S  I,  c  =  (-•  ■odal_predlcate(I,)  ftiae 

■odal_predlcata( t^)  ptlae 

■odal_predlcata( t.)  Ptlae  Tg 
A 

aiodal_predlcate(Ig)  ptiae 


The  syntactic  representation  of  a  Teaporal  Relevance  Assertion  is  the 
Banner  by  which  the  tiae  points  of  the  seaantic  value  ate  indicated.  The  above 
exaaples  aade  use  of  teaporal  operators  such  as  'ttiae',  ’after",  and  "while*. 
They  have  seaantic  interpretations  siatlar  to  those  described  in  Kroger's 
Teaporal  Logic  of  Proqtaas  (161.  Other  approaches,  such  as  Ladkin’s  interval 
calculus  [ 17 1 ,  are  also  applicable. 


Within  RSSS  theory  the  concept  of  functional  Reguireaent  aay  now  be 
defined. 

Definition  :  functional  Requireaent  DIO 

A  functional  Requireaent,  /Req^ i 1^,0^ ) ,  is  the  set  of  all  Teaporal  Relevance 
Assertions  j (O^a/i j( Ij j ) )  having  0^  as  a  coaaon  output  state  space. 

More  foraally  : 

w  i,j  : 

Tij(0i-/ijdij))  t  /Reqidi.Oi))  I 


This  definition  for  functional  Requireaent  constrasts  sharply  with  the 
traditional  definition,  A  aore  traditional  definition  eaphaslses  the  concept  of 
"function"  as  the  focus  of  a  requireaent,  rather  the  output  object  which  is 
required  to  have  the  functional  relationship  wrt.  to  a  set  of  input  objects. 
This  is  a  result  of  a  process-oriented,  an  exaaple  of  "how",  view  to 
requireaent  specifications  where  a  given  output  object  does  not  exist  until 
"produced*  by  the  function. 

Within  RESS  theory,  the  concept  of  functional  Requireaent  Specification  has 
the  following  definition. 

Definition  :  functional  Requireaent  Specification  Dll 

functional  Requireaent  Specification,  /RSpec(z,0),  la  the  set  of  all 
functional  Requlreaents  /Reqi(l<,Oj>  for  the  software  specification 
abstraction  level  having  I  as  Its  input  state  space  and  O  as  Its  output  state 
space  such  that  ; 

Will  (/Reqjdi,0i)  A  (Ij  c  I)  A  (©1  c  0)> 

(/Reqj(Ij,Oil  e  /RSpecd,©))  ) 


In  addition  to  separating  functional  Requireaent  Specifications  along  one 
syntactlc/seaantlc  duality,  Teaporal  Relevance  Assertions  and  functional 
Assertions,  RESS  theory  alto  separates  requireaent  inforaatlon  along  another 
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such  duality;  that  of  Mon>Functional  RequlraMnt  Specifications  and  Functional 
ftequireaent  Specifications. 

HESS  theory  considers  such  attributes  as  *aaintainable” ,  "understandable”, 
"aeaory  size  efficient",  etc.  to  fall  into  the  category  of  Non'*Functionai 
Requireaent.  Such  attributes  are  difficult  to  quantify  due  to  their  subjective 
non'-discrete  nature.  This  suggests  a  Fuszy-Set-Theoretic  approach  for  the 
specification  and  analysis  of  Non-Functional  Requirements.  The  "fuzzy-like” 
nature  of  Non-Functional  Requirements  is  an  accepted  truism.  Thus,  a  "level  of 
priority"  attribute  is  associated  with  the  Non-Functional  Requirement  within  the 
definition  of  Non-Functional  Requirement  Assertion. 


Definition  :  Non-Functional  Requirement  Assertion  D12 

A  Non-Functional  Requirement  Assertion.  nfReq^d^.O^) ,  is  the  j'th  assertion 
stating  a  required  attribute  of.  or  constralnt*^governin9,  the  design  intended 
to  satisfy  fReq^ ( 1^ .0^ ) . 


RBSS  theory  treats  Non-Functional  Requirements  to  be  constant  with  respect 
to  the  temporal  axis  of  the  system's  state  space.  Thus,  there  is  no  temporal 
assertion  binding  with  each  Non-Functional  Assertion  as  for  the  Functional 
Assertion.  Such  a  temporal  attribute  would  imply  software  self-modification,  as 
will  be  seen  later  in  the  discussion  of  software  design.  While  this  is  a 
computational  possibility,  it  does  not  normally  fall  in  the  domain  of  real-time 
embedded  systems  and  will  be  consequently  ruled  out. 


Definition  :  Non-Functional  Requirement  Specification  Dl3 

A  Non-Functional  Requirement  Specification.  nfR5pec( I .0) .  is  the  set  of  all 
n/Reqj^jdl^fOd  for  all  0i  c  o  associated  with  the  design  of  a  given 
abstraction  level.  <1.0>  oc  a  software  system. 


Software  Design  Specifications  in  RBSS  ^eory 

RBSS  theory  identifies  a  separation  of  software  design  specifications  along 
its  semantic/syntactic  boundaries.  This  separation  has  a  natural  isomorphic 
relationship  to  the  Functional  vs.  Non-Functional  Requirement  Specification 
duality  at  the  same  abstraction  level.  RBSS  theory  defines  Data  Transformation 
Design  as  that  specification  which  defines  a  partial  ordering  of  data-object- 
specific  transformations  whose  syntactic  and  semantic  composition  satisfies  some 
Functional  Requirement  from  the  set  of  Functional  Requirements  making  up  the 
/RSpec()  for  that  level  of  abstraction. 

In  addition.  RBSS  theory  defines  Architectural  Design  as  that  specification 
that  defines  a  data-type-specif ic  partial  ordering  and  modular  packaging  of  Data 
Transformers .  It  also  specifies  a  temporal  binding  of  specific  data  objects  to  a 
Data  Transformer  partial  order  which  is  logically  complete  and  consistent  with 
respect  to  the  set  of  Data  Transformation  Sequence  specifications.  The  syntactic 
organization  specified  by  Architectural  Design  has  the  goal  of  satisfying  one  or 
more  Non-Functional  Requirements  from  the  set  of  nfReq^ ( 2^ ,0^ )  making  up  the 
n/RSpecd  .0) . 

In  order  to  describe  and  reason  about  these  two  aspects  of  software  design 
a  number  of  additional  terms  must  be  defined. 

Definition  :  Canonical  Data  Transformation  D14 

A  Canonical  Data  Transformation.  Ac().  is  the  general  tern  for  che  discrete 
manipulation  of  either  the  syntactic  representation  or  semantic  value  of  a 
data  object,  or  set  of  data  objects.  to  produce  a  new  syntactic 
representation  or  semantic  value,  respectively. 

Naturally,  there  are  two  canonical  data  transformation  types;  a  syntactical 
transformation  and  a  semantic  transformation.  A  canonical  transformation  must  be 
object  specific  and  have  a  syntactic  or  semantic  result  which  contributes  to  the 
syntax  or  semantics  of  the  functional  assertion  it  Is  intended  to 
refine/satisfy.  Canonical  semantic  transformations  map  to  functional  relations 
within  the  postconditional  semantics  associated  with  the  functional  assertion. 
Prom  this  view,  a  data  transformation  sequence  is  simply  a  decomposition  of  a 
requirement  expression.  However,  this  stage  of  specification  requires  that 
deaign  choices  for  the  syntactic  reDresentation  of  the  data  objects  carrying 
semantic  Information  between  canonical  semantic  transformations,  be  made.  Such 
data  object  design  decisions  prejudice  the  syntactic  canonical  transformations 
needed  to  set  up  the  data  objects  for  the  "required"  semantic  transformations. 
This  also  implies  the  need  for  a  partial  ordering  of  the  transformations  which 
is  the  beginning  of  the  attachment  of  "process  orientation"  to  the  design  of  the 
solution.  The  next  two  definitions  describe  the  two  classes  of  canonical 
transformation  more  formally. 


\ 

x 


Definition  :  SeMntic  Value  Transforaation  015 

A  Semantic  Value  Transformation,  x  :«  Asv(y^ . . .yi^) ,  is  an  object  specific 
n-ary  operator  that  specifies  the  conversion  of  the  semantic  values  of  a  set 
of  data  objects  to  a  new  semantic  value  which  it  then  binds  to  a  pre-existing 
data  object  according  to  the  following  rule  : 

Let  X,  and  yi*««yn  <Ach  denote  some  data  object 


X  Asv(yi,...yn) 

<— > 

exlsts(8r<x) ) 

A 

Vie  (l...n)  :  [(sv(y^)  #  8v(x))) 
(sv(x)  -  sv(Asv(y2*...yn)) 


has  the  traditional  semantics  *the  values  are  equal  after  binding 
the  results  of  the  right  hand  side  to  the  data  object  of  the  left  hand 
side" . 

for  example  : 

Let  vel  denote  a  velocity  object 

d  denote  a  distance  object 

t  denote  a  time  object 

Then  vel  :>  asv(d,  t) 

<— > 

8v(asv)  •  ■  idealised  real  number  ^division* 

A 

8r(vel)  «  an  object  of  type  REAL 
A 

8v(vel)  *  "100.0  kph" 

A 

sr(d)  •  an  object  of  type  REAL 

A 

sv(d)  •  "100.0  km" 

A 

8r(t)  •  an  object  of  type  REAL 
A 

8v(t)  •  *1.0  hours" 

Definition  :  Syntactic  Conversion  Transformation  Dl6 

A  Syntactic  Conversion  Transformation,  x  *  >yn)  ^  object 

specific  n-ary  operator  which  converts  or  combines  the  syntactic 
representation  of  elements  of  its  domain  to  a  single,  possibly  non-primitive, 
element  in  its  codomain.  Such  transformations  conform  to  the  following  rules. 

Let  x,y  each  denote  some  data  object 


X  Asriy) 

<— > 

(8c(y)  #  8r(x)) 

A 

(8v(y)  -  sv(x) ) 

A 

(8v(Asr)  -  f():  8r(x)  ^  sr(y) 
sv(x)  8V(X)) 

for  example  : 

Let  vel  denote  a  velocity  object 

vel*  denote  an  additional  velocity  object 

Then  vel'  AsrCvel) 

<“> 

8v(A8r)  «  REAL_to  INTEGER  conversion 
A 

sr(vel)  «  an  object  of  type  REAL 
A 

8v(vel)  «  "100.0  kph* 
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sr(velM  -  ftn  object  of  type  IMTBGBR 
A 

sv(vel» )  -  "100  kph* 


RESS  theory  requires  for  each  functional  Assertion  one  or  more  sequences  of 
Data  Transforaations  such  that  the  seaantic  result  of  each  Data  Transformation 
Sequence  is  equal  to  the  semantic  relationship  denoted  by  the  Functional 
Assertion.  Also  the  syntactic  result  of  each  sequence  is  equivalent  to  the 
output  state  space  of  the  Functional  Assertion.  The  number  of  such  sequences  is 
determined  by  the  number  of  mutually  exclusive  functional  relations  present  in 
the  postconditional  semantics  of  the  functional  Assertion. 


Definition  :  Data  Transformation  Sequence  D17 

A  Data  Transformation  Sequence,  aSeqt ^ j «  is  a  partially  ordered  set  of 
Canonical  Data  Transformations,  Asv<t^s  and  &8r()'s,  such  that  : 

sv(  ASeqj^  j  ( j  ,0^  ) )  a  soneP(Ij^j)  (  ASeq^j  }  BoaeR(  1^  j  ,0^  ) 

-  svCOj  -  /ijdij)) 


sr(  ASeq^  j  ( 1  j  ,0^  ) )  .0 
ar(ASeqij(Iij,Oi)).I 
8r(SSeqij(Ii j,0i) ) .A 


Oj  -  st(Oi-/ij(Iijn.O 

lij  - 

ASeq^j  •  partial  order  of  n  Ac()*s 


The  semantics  of  a  qiven  ASeq^j  may  be  said  to  be  equal  to  the  semantics  of 
its  associated  functional  Assertion'^only  under  the  following  condition. 

sv<ASeqij(li^,Oi))  .  sv(Oj  - 

<-> 

iB_well_formed(sr(A8eq£ j(Iij,0i)).A)_wtt._0|  • 

The  symbol  "wet."  stands  for  "with  respect  to”. 


Definition  :  ( )_is_well^formed_wct._( )  DIB 

The  definition  of  the  predicate  ".is  well  formed  wet.  "  is  an 
Inductive/recursive  one  according  to  the  following  rules  : 

1,  (X  Aciyj, . ..yjj) )_i8_well_formed_wrt._0i  -  ^ijtlij) 


<-> 

'k-j^  *k  *  Ol 

Ik-j^.-.n  yk  •  lij 

SV(AC)  ■  8V(/^j) 


where  Ac  is  some  Asv  or  Asr 


2.  (x  j-  Acjl  Ac2(yi .y^)  #»••  ACg|(''l»  •''1  J_i8_we7 Informed 

_wrt._(0i  •  /ijt^ij)) 

<—> 

(x  Aci(i2r  •  •  »*«n_is_well_formed_ 

_«rt._(Oi  -  /iji(tK.2...,  *k>>» 

A 

V  q  e  (2...mj  ;  ((Xg  4Cq(Ij j > >_ix_w»ll_for»*<J 

_wct._(xg  -  /ijq(Iij)>) 
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As  a  slaple  exaapla  : 

Let  8  be  an  output  data  object 
sr(8)  «  BBAL 
Bv(8)  «  kph 

X  be  an  input  object 

8r(x)  •  INTEGER 

6v(x)  >  klloaetera 

y  be  an  input  object 

8r(y)  -  ARRAY  I0..31  o£  CHAR 

sv(y)  •  hundredths  of  hours 

*  be  a  REAL  nuaber  division  operator 


Then 


8  create  REAL  object() 

z  f(convert_liiTEGBR_to_RBAL(x), 

convert_ARRAyofCHAR_to_RHAL(y) ) 


The  Data  Transforaation  Sequence  also  serves  as  the  starting  point  for  a 
foraal  definition  of  requireaent  satisfaction  traceability  within  rbss  theory. 


Definition  :  ( )_i8_r-8ati8f ied_by_( )  D19 

This  predicate,  is_P-sati6fied_by_,  states  the  condition  under  which  a  given 
Punctional  Assertion  aay  be  defined  as  being  Functionally  satisfied  by  a 
given  Data  Transforaation  Sequence. 

(Oi  -  /i j( j ) )_iB_P-satisf ied_by_( ASeq- j( ) 

< — > 


sv{ASeqij{Iij,Oi))  -  sv{Oi  -  /ijdij)) 


RBSS  theory  proposes  the  specification  classes  Data  Transforaation  Set,  and 
Data  Transforaation  Specification  in  order  to  provide  terns  for  the  grouping  of 
all  transforaation  sequences  which  result  in  the  creation  and  seaantic  binding 
of  the  sane  output  data  object  or  sane  eabedded  systea  abstraction  level. 


Definition  :  Data  Transforaation  Set  D20 

A  Data  Transforaation  Set,  ASet^^(l^4,o^),  is  the  set  of  all  Data 
Transforaation  sequences  Aseq^^di  )  ''having  0^  as  its  associated  output 
state  space  and  0^  •  ^ij^^ij)  Functional  Assertion. 


Definition  i  Data  Transforaation  Specification  D21 

A  Data  Transforaation  Specification  ASpec(l,0)  Is  the  set  of  all  Data 
Transforaation  Sets  in  the  following  aanner: 

V  Oi  c  O  ;  IASetijfIij,Oi)  ->  ASetij(lij,Oi)  c  aSpec(I,0)] 


RBSS  theory  delegates  the  ''fuz8y"-satisfaction  of  Non-Functional 
Requireaents  to  the  specification  class  "Architectural  Design."  The  design 
process  resulting  in  the  specification  of  this  class  has  the  goal  of  satisfying 
such  difficult  to  quantify  requireaents  like  "alniaua  possible  aeaory  space", 
"easy  to  aaintain",  "ainiaua  inter-aodular  coupling",  etc.  The  priaitive  in  this 
specification  class  is  the  Data  Transforaer. 


Definition  :  Data  Transforaer  D22 

A  Data  Transformer,  &Dtqdg,0q)»  is  a  generalisation  of  the  semantic  and 
syntactic  attributes  of  ^oni  or  more  total  or  partial  Data  Transforaation 
Sequences,  unlike  a  68eq(),  which  is  data  object  ppecific,  a  ADt( )  is  data 
object  generic  but  data  type  specific. 

sv(ADtg(Ig,Og))  a  soaeP(Ig)  {  ADtg  |  soaeR(Ig,Og> 

Sr(ADtg(Ig,Og)).I  -  Ig 
8r(aDtg(Ig,0g)).0  -  Og 

8r(ADtg(Ig,0g)).A  -  ADtg 


a 
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A  Data  TcansforAer  la  a  software  design  eleaent  which  qroups  subsets  of 
6Seq( )  partial  orders  In  a  couon  packages  for  the  purpose  of  "fussy'-satlsfylng 
"real  estate  oriented”  Non-Punctional  Requiresents;  such  as  the  amount  of  memory 
space  or  temporal  axis  length  available  for  carrying  out  a  given  function.  A 
"fussy"  predicate  relationship  describing  the  degree  of  satisfaction  of  a  given 
n/Req( )  will  ^  investigated  as  an  addition  to  RE88  theory.  Such  a  relation  will 
permit  each  nfReqC )  to  be  traced  to  those  aDt(l's  which  arc  involved  in  its 
satisfaction. 

Data  Transformers  are  an  abstraction  of  such  implementation  specification 
concepts  as  "software  system”,  at  the  highest  level  of  abstraction,  "task”  and 
"procedure",  at  intermediate  levels,  and  "statement”  and  "instruction”  at  low 
levels  of  abstraction. 


Definition  :  Data  Transformer  Sequence  D23 

The  Data  Transformer  Sequence,  SDtSeqC),  is  a  partial  order  of  aDt()'s  which, 
when  bound  to  specific  subsets  <r^j,0£>  c  <i,o>  subsume  the  state  spaces  and 
semantics  of  one  or  more  6Seq(ii j,0^)^a  and  the  Temporal  Relevance  Assertions 
governing  the  Functional  AssertiQns  satisfied  by  each  &8eq( j ,0^ ) . 

sv(  AOtSeq^  j (1^ j ,0^ ) )  m  sonePd^j)  A  RelevanceP(i|  j,0£) 

(  ADtSeqjj  ) 

8omeR<I^ 

srUDtSeqijdij,©^)).!  - 
sr(aDtSeqij(lj^j,0i)).0  • 
sr(sv( ADtSeq^ j ( j,0i ) ) i .P  -  someP(l^j) 
srdv(60tSeq^j(l^j,0^) ) )  .Rp  ••  RelevancePd^ j) 

8r( 8v( SDtSeqj^  j d|  j  ) ) )  .R  -  someR(Ij^j) 

The  Data  Transformer  Sequence  constitutes  the  second  and  third  points  at 
which  requirement  satisfaction  traceability  relations  are  recognised  within  RCS8 
theory. 


Definition  :  ( )_i8_A-sati8f led^by_( )  024 

The  predicate,  is  A^satisfied  by_,  states  the  condition  under  which  the 
semantics  of  a  given  6Seq< )  may^be^defined  as  being  Architecturally  Batisfied 
by  a  given  6DtSeg(). 

(  hSeq^  j  ( j  ,0| )  )__i8_A-sati8fied_by_(6DtSeq|ji<  ) ) 


8t(&Seqjj(lij,0i) )  ,I  c  8r(60tSeq|(l^d|(^,0}^) )  .1 

sc(6Seqij(ljj,0i)).0  c  8r(  ADtSeqij^djiirOj^) )  .0 
A 

sv(AS«q^j(Ijj,Oi))  ->  .vCADtSaqi^^dl^^cOi^)  I 


Daflnltlon  :  ( )_lA_T-»atlA£l«d_by_( )  025 

Tha  pradicata,  ia_r-aatlaf lad  by  ()>  atataa  tha  condition  undac  which  the 
taaporal  saaantTcs  of  Tj ^ ^ ) )  aca  satiaflad  by  a  calavanca  pradlcata 
which,  as  part  of  the’  pracondltlon  of  a  qivan  ADtSaq|(i(I|(X >oii) t  f*  > 
caflnaaant  of  soaa  coaponant  of  j(I j j ) ) . 


(Tij(Oi-/ij(Iij) )  )_is_T-satlsftad_by_(ADtgaq,(^(I,j^,0)()  I 


sr(Tij(Oj-/ij(Iij))).I  c  sr(ADtaaqKx<Ikl'0|[)).l 

st(Tij(0x-/ij(Iij))).0  c  sr(ADt8aqki(I|il'0k)).0 

•v(Ti  j(0i«/ij(lxj  ) ) )  ->  st(sv(  ADt8aqkx(Ikl><*k) )  > 
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ThuSr  the  connections  between  Oats  Transformers  that  fora  the  Data 
Transformer  Sequences  may  be  considered  an  abstraction  of  the  implementation 
specification  concepts  of  "task  invocation",  "procedure  call",  "sequence",  and 
"concurrence".  Bach  Data  Transformer  Sequence  specifies  a  binding  of 
data^object-independent  Data  Transformers  to  specific  data  objects.  The  result 
is  an  execution  path  from  the  input  state  space  of  the  abstraction  level  to  the 
output  state  space.  This  execution  path  through  Data  Transformers  must  be  chosen 
to  satisfy  the  semantic  and  syntactic  requirements  specified  by  one  or  more 
aSeq()'s  under  the  temporal  constraints  specified  by  the  j  ( 1^4 ) ) '  s 
associated  with  the  whose  functional  semantics*'  and  syntax  are 
satisfied  by  the  SSeq()*s.‘'  In'*  essence  it  Is  a  re-connection  of  the  partial 
aSeq()'8  within  the  individual  Data  Transformers  such  that  the  set  of  Data 
Transformation  Sequences  is  recreated. 


Definition  :  Architectural  Design  Package  D26 

An  Architectural  Design  Package,  Adp4(I,0),  is  the  i'th  set  of  all  aDt()'s 
whose  grouping  together  act  to  "fuzzy"-sati8fy  such  qualitative 
Non-Punctional  Requirement  types  as  "Easily  modifiable”,  High  degree  of 
reusability”,  etc.  for  the  Specification  Abstraction  bevel  associated  with 
<I,0>. 


An  Architectural  Design  Package  has  no  function  other  than  to  address 
Non-Punctional  Requirements,  in  this  attribute  it  is  an  abstraction  of 
implementation  specification  elements  such  as  an  Ada  package  or  pascal  module. 


Definition  :  Architectural  Design  Specification  D27 

An  Architectural  Design  Specification,  Ad8(l,0)  is  the  set  of  all 
Architectural  Design  Packages  for  a  given  Specification  Abstraction  Level. 


Now  that  the  above  terns  have  been  been  defined,  "System”,  "Embedded 
System",  and  "Real-Time  Embedded  System"  can  be  defined  within  the  domain  of 
BBSS  theory. 


Definition  :  System 


A  System,  S(1,0),  is  a  single  Data  Transformer  with  data  type  specific,  but 
data  object  independent,  input  state  space  srd)  and  output  state  space 
sr(0) . 


Definition  :  Embedded  System  D28 

An  Embedded  System,  BS(I,0),  is  an  S(l,0)  In  which  the  input  state  space 
srd)  and  the  output  state  space  sriO)  is  finitely  bound  to  specific  data 
objects  and  for  which  there  exists  a  deterministic  response  state  8v(0) 
within  the  domain  of  the  output  state  space  8r<0)  for  any  stimulus  state 
svd)  possible  within  the  domain  of  the  input  state  space  srd). 


Definition  :  Real-Time  Embedded  System  D29 

A  Real-Time  Embedded  System,  RBSd,0),  is  an  B5d,0)  in  which  "time"  is  a 
member  of  the  input  state  space  srd)  with  one  or  more  of  the  output  data 
objects  sr(0|)  c  sr(0)  dependent  on  a  relation  between  the  input  data  objects 
srd^j)  c  srd)  of  its  aseq(l^j,0^)  and  "time". 


Basic  Axioms  of  RBSS  Theory 

The  following  three  axioms,  along  with  the  above  definitions,  form  the 
l*nsls  for  RESS  theory.  These  axioms  were  first  discussed  in  different  forms  in 
t  IS),  [19). 

Axiom  of  System  Hierarchy  A1 

Any  given  RBS[I,0)  is  a  single  Data  Transformer  within  a  Data  Transformer 
Sequence  of  a  higher  level  of  Specification  Abstraction. 

The  implication  of  Al  is  that  for  any  given  RBSd,0),  the  specifications 
srd),  svd),  8r(0),  sv(0),  Precondltiond ) ,  Relevance  Predicated  ,0) ,  and 

i^nstconditiond  ,0)  are  a-priori  inheritable  from  the  Architectural  Design 
Specifications  of  a  higher  level  system. 


T 


1M8 

Asioa  of  Dotorainistic  Bosponto  a2 

A  ••■Antic  value  of  th«  output  stat*  spae*  of  an  BB8(I,0)  is  •p«cifiabl«  for 
any  ••■antic  value  of  ite  input  atate  apace. 

Aa  a  corollary  :  for  any  9iven  BB8(I«0), 

wp(RBS<l,0),  ia_valid(0))  «  true  wrt.  I 

where  wp( )  ia  Dijkatra'a  veakeat-precondition  predicate  tranaforner.  (201 


Axloa  of  Teaporal  Relevance  A3 

The  Functional  Aaaertiona  required  to  be  aatiafied  by  the  deaign  of  an 
RES(I»0)  ace  relevant  to  the  Data  Tranaforaation  Sequencea  of  ita  "parent* 
•yatea  only  at  apeclflably  diacrete  pointa  In  tiae. 

Theoreaa  of  BBSS  Theory 

The  followinq  ia  a  partial  Hat  of  theoreaa  of  RBB8  theory.  They  are 
Included  to  provide  a  overview  of  aoae  of  the  additional  attributea  of 
RBSS-theoretic  apecif icationa  that  are  not  iaaediately  noticeable  froa  the  above 
definitiona  and  diacuaaiona.  Concepta  auch  aa  *av  conalatency”  and  ”av 
coapleteneaa*  for  atate  apacea  are  left  to  their  Intuitive  definitions.  t5 
through  TlO  and  T12  are  expanded  in  order  to  give  a  detailed  picture  of  teaporal 
and  function  coapleteneaa  and  conalatency  deacriptiona. 


Theorea  of  State  Space  *sr”  Coapleteneaa  T1 

ForAll  RBS(Z,0),  sr(l)  and  artO)  are  coapletely  specifiable. 


Theorea  of  State  Space  *ar*  Consistency  T2 

ForAll  RBS(i,0),  sr(i)  and  sr(0)  ace  consistently  specifiable. 


Theorea  of  State  Space  *av*  Coapleteness  T3 

ForAll  RBS(I«0)«  sv(i)  and  sv(0)  are  coapletely  specifiable. 

Theorea  of  State  Space  *sv*  Consistency  T4 

ForAll  RES(lfO)«  8v(I}  and  sv(0)  are  consistently  specifiable. 


Theorea  of  Functional  Requireaent  Teaporal  Coapleteness  T5 

A  Requireaent  Specification  ia  seaantic-'teaporally  coaplete  if  ForAll  data 
objects  of  the  output  state  apace  the  required  sv(data  object)  is  defined  by 
a  Functional  Assertion  for  all  tiaepoints  beginning  at  the  object's  own  t-0 
(established  upon  its  initialization). 

In  other  words  : 

V  /RSpecd^O)  :  (ia_sv_Teaporally_Coaplete(fRSpec(IrO) ) 

< — > 

V  Oj  e  O 

3  Tij(Oi-/ij(Iij))  :  (T  e  avtTi^ ^(1 j ^ ) ) )  J 


Theorea  of  Functional  Requireaent  Teaporal  Consistency  T6 

A  Requireaent  Specification  ia  seaantic>teaporally  consistent  if  ForAll  data 
objects  of  the  output  state  space  the  sv<data  object)  is  not  defined  by  aore 
than  one  functional  assertion  at  the  aaae  tine  point  on  the  teaporal  axis. 

In  other  words  : 

V  /RSpec(I,0)  :  (Is_sv_Teaporally_Consistent(/R5pec(I ,0) ) 


A 
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V  Oi  c  o 


E  /Reqjdj.Oi)  ! 
V  i,  j,  k  : 


Uil)) 


e  /Rdq^dj.O^)) 

€  /R«qjdj,0()) 

^  Tik(Oi-/lk<Iik>> 


) 


(svlTijlOj./ijdij)))  U  •v(Tn(Oi-fi|,di|t)))-  (9))1 


Theorea  of  runctlonal  Raquir»«nt  *sr*  Coapletene'  T7 

rorAll  RESd,0) 

FotAll  tlMpointt  Ti  ^  (tla«  Ti  •  0 
rocAll  sr(Oj)  c  sr(0) 

TheceExiitB  a  ayntactic  calatlonal  aapplnq 

ar(Oj)  -  ir(/j  j  )  (  ar(  Ij  j  ) )  :  (srd^j)  c  acd)l 


TheoroB  of  Functional  Raqulcaaant  'ac*  Conalatancy  T8 

FocAll  RESd.O) 

FotAll  l,j,k,l  : 

((ariosi  -  ac(/^  j  )  (acd^  j  I ) 

ar(Oi)  -  ar(/i|j)  (ardii,) ) ) 
arlOj)  -  ar(Oi) 

Btdjj)  -  atdii,)) 


at(/ij)  -  still,)  1 

Theoteai  of  Functional  Raquitaaant  *sv'  CoBpletenaaa  T9 

FotAll  RESd.O) 

FotAll  tiaapointa  ti  2  ttlaa  Ti  -  0 
FotAll  at(Oi)  c  sc(0) 

ThataExiata  a  aeaantic  telational  aappinq 

atlOj)  «  at(/ij)<ardij))  :  (srdij)  card)) 


Tliaoraa  of  Functional  Requicaaent  *sv*  Conalatancy  TIO 

FotAll  RESd.O) 

FotAll  i.j.k.l  : 

((avlOi)  -  av(/ij)(avdij) ) 

av(Oi)  -  av(/i|,) (avdi),) ) ) 

av(Oi)  -  av(Oi) 

svdij)  -  avdii,) ) 


sv(/ij)  -  avli,,)  1 


Tliaotaa  of  Functional  Halation  Claaaif Ication  Til 

Eacli  runctlonal  Ralatlonahip  praaant  in  tlia  poatcondttion  asaantica  of  a 
Functional  Aaaattion  aay  ba  claasifiad  aa.  ot  dacoapoaad  into.  ait)iac 
'aaaantlc*  or  ’ayntactic*  wit)i  taapact  to  ttia  atlOj)  and  avdj.)  ovacw)iic)i 
t)ia  ralationatiip  is  taquitad  to  )iold.  '' 

T)taotsa  of  Data  Tranaforaation  Saquanca  T12 

TltaraExiata  a  Data  Tranaforaation  Spacif ication  ASaqdij.Oi)  for  all  autually 
axcluaiva  Functional  Halations  /iiii  FotAll  Functional  Aaasrtiona  0^  - 
/i^di^)  of  all  /Reqdi.Oi)  in  tlia  '’/RSpacd.O)  of  a  qivan  abstraction  laval 
for  any  aabaddad  systan  RtSd.O). 
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Theorem  of  How/Hhat  Duality  T13 

For  any  given  Specification  Abstraction  Level,  the  complete  set  of  Functional 
Assertion  Specifications,  the  *what*  for  that  level,  are  logically  equivalent 
to  the  Data  Transformer  postcondition  specifications,  part  of  the  "how”  of 
the  previous  Specification  Abstraction  Level. 


Theorems  of  Architectural  Design  Derivation  T14.1 

For  any  given  Specification  Abstraction  Level,  the  Data  Transformation 
Sequence  specifications  for  that  level  are  logically  implied  by  the 
Functional  Assertion  specifications  and  *fuzsy”''logically  implied  by  the 
Non-Functional  Requirements  for  that  same  level. 


T14.2 

For  any  given  Specification  Abstraction  Level,  the  Relevance  Predicate 
governing  the  binding  of  input  and  output  data  objects  with  Data  Transformers 
is  logically  Implied  by  Che  Temporal  Relevance  Assertions  constraining  the 
associated  Functional  Assertions. 


An  Application  of  RB88  Theory 

The  intended  application  of  RESS  theory  is  as  a  deductive  inference  model 
upon  which  to  base  an  Al-enhanced  Computer-Aided  Specification  Engineering, 
CASE,  environment.  The  axioms,  theorem,  definitions,  and  associated  rules  of 
Inference,  when  expressed  in  mathematical  logic,  enables  the  application  of  an 
inference  engine  approach  to  specification  collection  and  analysis. 
Slmpllstlcally,  the  entry  of  specification  information  can  be  used  to  trigger  a 
forward  chain  of  reasoning  causing  the  correct  forms  of  analysis  of  the  new 
information  with  respect  to  the  model  and  the  previous  specif ication  contents  of 
the  knowledge  base,  if,  during  such  analysis,  required  specification  information 
is  found  to  be  missing  from  the  knowledge  base  a  goal  directed,  ie.,  backward 
reasoning,  process  can  be  triggered  prompting  the  collection  of  the  missing 
information.  A  complete  and  consistent  set  of  specification  information  will  be 
provable  as  a  theorem  of  RESS  theory. 

As  stated  earlier,  current  generation  CASE  tools  have  very  little  real 
understanding  of  the  specification  information  they  are  responsible  for 
collecting  and  "analysing” .  They  act  as  slaves  to  the  user  allowing  the  creation 
of  graphic  language  specifications  according  to  very  simple  syntactic  rules 
without  enforcing  any  semantic  constraints  on  the  information  specified.  They  do 
not  have  the  capability  of  assisting  the  user  in  semantic  completeness  or 
consistency  analysis.  Nor,  are  they  capable  of  requesting  or  suggesting  specific 
information  which  would  correct  completeness  and/or  consistency  problems. 

An  Al-enhanced  CASE  environment,  based  on  the  model  proposed  by  RESS 
theory,  should  be  capable  of  performing  the  above  analysis  types  [21,  22,  23). 
It  should  also  be  capable  of  assisting  in  the  selection  of  design  choices  based 
on  the  heuristics  which  all  competent  software  engineers  apply  Instinctively  to 
their  software  designs.  These  capabilities,  and  others  such  as  automatic  code 
generation  and  correctness  proofs,  provides  the  software  engineer  with  some  of 
the  tools  now  available  to  the  digital  hardware  engineer  via  CAD  systems. 
Current  day  CAD  systems,  based  on  Internally  manipulated  knowledge  of  the 
semantics  of  NAND  gates  and  Boolean  algebra,  for  example,  provide  assistance  to 
hardware  designers  only  dreamed  about  in  the  software  design  domain. 


Conclusion 


At  the  time  1  submitted  the  abstract  for  this  conference  I  was  interested 
in  expressing  a  number  of  concepts  that  I  and  a  colleague  had  been  working  on 
related  to  the  identification,  analysis,  specification,  and  application  of 
requirements  for  real-time  embedded  systems.  These  concepts  involved  a 
hierarchical  view  of  specification  levels,  Al,  which  is  an  extension  of  the 
traditional 

System  Ret^uirements 
V 

System  Deslan 
V  V 

Hardware  Requirements  Software  Requirements 


hierarchy  but  which  generally  falls  into  flatness  at  the  hardware  and  tottware 
levels 


1 


Hardware  Requirenentfi 

I 

V 

Hardware  Design 

I 

V 

Hardware  inplenentation 


Software  Requi resents 

V 

Software  Design 

V 

Software  Implenentation 


instead  of  recursively  descending  down  successively  refined  abstraction  levels 
within  a  software  and  hardware  specification  hierarchy.  In  addition,  l  felt  that 
there  was  little  work  available  identifying  and  fornalizing  the  concepts  of 
senantic  cospleteness  and  semantic  consistency  for  requirement  specification  and 
analysis.  The  same  is  true  in  regards  to  the  semantic  relationships  between 
requirement  specifications  and  design  specifications  (implementation  being  the 
least  abstract  level  of  design  specifications).  Semantics  are  generally 
discussed  only  in  the  context  of  source  level  programs  and  programming 
languages.  The  only  such  consistency  and  completeness  attributes  definable  for 
most  current  approaches  to  requirement  specification  is  syntactic  in  nature.  For 
example,  "level  balancing"  within  the  "structured  analysis"  camp. 

Prior  to  this  paper,  the  work  we  had  done  was  primarily  conceptual  and 
experimental  [24].  The  axioms  and  theorems  were  expressed  abstractly  and  were 
unproven.  And  the  specification  classes  and  their  relationships,  which  were  the 
focus  of  these  axioms  and  theorems,  were  not  formally  defined.  After  beginning 
the  paper  l  quickly  found  that  the  formal  expression  of  the  axioms,  theorems, 
and  rules  of  inference  of  HESS  theory;  which  was  my  original  intention;  was  not 
possible  without  first  developing  a  vocabulary  and  set  of  logical  operators  with 
precise  definitions.  This  would  not  be  a  surprise  to  a  mathematician.  However, 
as  an  electrical  engineer  currently  working  in  the  development  of  real-time 
avionics  software,  the  amount  of  effort  required  to  do  just  this  much,  was  both 
unexpected  and  very  fruitful. 

This  paper  consists  primarily  of  a  first  draft  of  a  basic  subset  of  this 
vocabulary  and  operator  set.  However,  through  the  systematic  presentation  of 
this  set,  it  does  present  a  picture  of  the  model  of  software  specifications 
proposed  by  HESS  theory.  While  this  model  is  somewhat  non-traditional ,  it 
hopefully  raises  a  number  of  interesting  and  valid  perspectives  on  the 
specification  problem. 

The  emphasis  on  the  semantic  properties  of  specif ication  and  the  temporal 
aspects  of  all  real-time  systems,  beyond  that  of  state  transitions,  attempts  to 
bring  into  focus  two  areas  of  major  shortcomings  in  most  approaches  to 
requirement  specification  and  analysis.  Partitioning  of  design  speci fication 
classes  into  object  specific  Data  Transformation  Sequences,  which  has  as  its 
focus  a  system^  Functional  Requirements,  and  type  specific  Architectural 
Design,  with  a  focus  of  "fuzzy"-sati6fyin9  the  Non-Functional  Requirements  while 
subsuming  the  Data  Transformation  Sequences,  proposes  a  separation  of  concerns 
which  can  assist  the  designer  in  both  identifying,  justifying  and  quantifying 
design  decisions. 

The  application  of  a  Fuzzy-Set-Theoretic  approach  to  the  specification, 
management,  and  application  of  Non-Functional  Requirements  shows  a  number  of 
possible  benefits  and  applications  in  the  area  of  guiding  design  tradeoffs 
during  the  design  selection  and  specification  stages  of  a  development. 

The  final  goal,  that  of  fully  specifying  and  proving  the  soundness  and 
completeness  of  RESS  theory,  is  the  subject  of  a  continuing  effort.  In  this 
light  "RESS  theory"  should  be  referred  to  as  "RESS  hypothesis".  An  additional 
goal  is  the  intended  application  of  this  theory  as  the  deductive 
"proof-theoretic"  model  upon  which  an  Al-based  real-time  embedded  system 
specification  assistant  is  developed  and  implemented.  The  vocabulary, 
definitions,  and  specification  relationships  developed  during  the  work  on  this 
paper  has  definitely  moved  these  goals  a  large  step  closer. 
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DISCUSSION 


ILBenner,  US 

What  is  the  relationship  between  REFINE  and  Z? 

Author’s  Reply 

REFINE:  REFINE  is  a  tool  capable  of  transforming  a  very  high  level  language  program,  written  in  REFlNE's  own 
lai^uage  “V",  into  progressively  lower  level  programs,  still  in  until  the  level  of  the  program  is  such  that  it  is 
translatable  from  directly  into  a  target  source  code  language.  incorporates  set  theoretic  and  proof  theoretic 

ccMistnicts  so  it  is  possible  to  express  declaratively,  requirement  and  abstract  design  specifications.  However,  REFINE 
does  not  embody  any  inherent  model  of  what  such  specifications  should  look  like,  what  defines  a  complete  and 
consistent  set  of  specifications,  or  how  to  go  about  requesting  such  specifications  from  a  user.  These  are  the  areas  in 
which  my  work  on  RESS  theory  is  concerned.  REFINE  acts  likea  compiler  which  a  case  tool  base  on  the  model 
proposed  by  RESS  theory  would  act  as  an  intelligent  buUder/collector  of  the  class  of  information  which  would  be 
suitable  for  expression  as  a  “program”  which  REFIN^E  would  “compile". 

Z:  Z  is  a  language  useful  for  expressing  specificatiems  in  a  formal  manner.  RESS  theory  defines  what  information  is 
required  to  be  expressed  formally  in  some  language  like  “Z” 


A.O.Ward,  UK 

How  do  you  intend  to  educate  the  users  of  formal  methods  in  your  organization? 

Author’s  Reply 

1  no  longer  believe  it  to  be  either  possible  or  practical  to  try  to  educate  currently  employed  software  engineers  in  the 
required  discrete  maths  and  predicate  calculus  for  application  in  formal  specification  methods.  It  requires  a  shift  in  the 
engineer's  view  of  what  mathematics  is  all  about,  from  continuous  mathematics  to  discrete.  This  conceptual  shift  seems 
to  be  very  difficult  or  undesirable  to  most  engineers.  Instead,  my  efforts  are  now  focused  on  the  development  of  an 
axiomatic/deductive  model  which  can  be  used  as  a  foundation  for  an  expert  system-based  ca.se  environment  in  which 
the  “expertise”  is  that  of  a  software  engineer  that  docs  apply  forma)  specification  techniques.  This  approach  buries  the 
formal  mathematics  inside  the  case  environment  with  the  environment  providing  a  more  informal  view  of  the 
information,  such  as  data  flow  and  control  flow  diagrams.  The  advantage  of  this  approach  is  that  the  forma) 
specification,  built  internally  by  the  environment  from  an  informal  user  view  can  then  be  analyzed  for  much  more 
complete  and  rigorous  definitions  of  attributes  such  as  completeness  and  consistency  (semantic  a.s  well  as  syntactic) 
based  on  the  axiomatically  characterized  mtxlel. 


A,O.W«rd,  UK 

The  REFINE  tool  is  designed  to  describe  the  process  of  successive  transformarion.s  in  a  formal  context  as  well  as  the 
results  of  such  .steps  and  hence  differs  from  mainstream  formal  methods  .such  as  Z  and  VDM.  But  like  many  such  tools 
it  lacks  a  method  that  will  incrementally  collect  information  in  such  a  way  as  to  encourage  formal  expression.  Both 
methods  and  tools  are  required  for  successful  application  of  formality. 

Author’s  Reply 

I  agree,  but  would  like  to  add  that  prior  to  “methods  and  tools”  there  must  be  an  underlying  theory  which  acts  as  the 
foundation  of  any  basis  for  methods  which  must  then  be  supported  by  appropriate  tools.  REFINE  is  a  tool  which  is 
capable  of  taking  a  given  set  of  formal  specifications,  when  translated  into  “V”.  and  transform  them  into  a  potential 
implementation  at  the  source  code  level.  The  degree  that  this  code  is  usable  as  actual  application  software,  rather  than 
prototype  software,  is  a  function  of  the  constraints  imposed  by  the  non-functional  requirf;ments  of  the  particular 
application.  Also,  the  degree  to  which  REFINE  can  incorporate  user  directives  on  priorities  of  non-functional 
requirement  satisfaction  and  the  heuristic  rules  necessary  to  guide  the  transformations  selected  for  this  satisfaction  is  a 
key  to  actual  application  code  generation.  If  these  capabilities  can  be  made  robust  enough,  REFINE  could  be  a  very 
valuable  addition  to  a  case  environment  capable  of  constructing  formal  specification  suitable  for  translation  into  “V”  for 
input  to  REFINE.  This  is,  in  fact,  a  direction  my  colleague,  Mark  Blackburn,  is  pursuing. 
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SUMMARY 

The  use  of  Ada  In  avionics  and  other  systems  Is  assuming  more  Importance  due  to  a 
growing  body  of  national  policies  dictating  Its  use  In  mission  critical  systems.  This 
has  created  a  need  for  software  engineering  techniques  that  Incorporate  Ada  concepts 
so  that  the  transition  from  a  system  design  to  an  Ada  Implementation  Is  more  easily 
achieved.  One  of  the  most  common  techniques  Is  to  use  an  Ada-based  program  design 
language  CAOL).  This  paper  surveys  the  current  state  of  practice  In  Ada-based  program 
design  languages  by  examining  some  leading  reports  on  the  subject.  Among  the  more 
Important  efforts,  we  discuss  the  surveys  of  existing  ADLs  conducted  for  the  US  Naval 
Avionics  Center  (NAC),  the  Institute  of  Electrical  and  Electronics  Engineers  Reconnended 
Practice  for  AOLs,  the  ADL  guidelines  produced  for  Transport  Canada,  and  the  ADL 
guidelines  produced  for  the  NAC.  We  note  that  the  state  of  practice  is  considered  to 
be  too  Immature  for  standardisation.  However,  we  summarise  some  of  the  major  findings 
and  point  to  future  directions. 


1 .  Introduct Ion 

The  use  of  Ada  In  avionics  and  other  systems  Is  assuming  more  importance  due  to  a 
growing  body ‘Of  national  and  International  policies  dictating  Its  use  In  mission 
critical  systems.  For  example,  within  NATO,  Ada  Is  the  specified  language  for  the  14 
nation  funded  portion  of  the  NATO  Command,  Control  and  Information  System.  Furthermore, 
because  of  the  Inherent  advantages  of  Ada,  many  companies  and  national  organisations 
are  making  Ada  the  language  of  choice  even  where  the  force  of  policy  does  not  dictate 
Its  use. 

While  Ada  has  specific  features  to  facilitate  the  design  and  Implementation  of 
systems,  a  programming  language  by  Itself  cannot  address  all  aspects  of  the  software 
development  life  cycle.  One  of  the  most  common  techniques  to  bridge  the  gap  between 
design  and  Implementation  Is  a  program  design  language  or  PDL.  When  a  PDL  Is  Ada- 
based  It  Is  often  referred  to  as  an  ADL.  An  ADL  has  potential  utility  for  not  only 
avionics  but  for  all  Ada  Implementations. 

This  paper  will  survey  the  state  of  practice  In  ADLs  by  examining  the  most 
Influential  recent  reports  on  ADLs.  This  Includes  survey  reports  on  existing  ADLs, 
the  results  of  an  important  standardisation  attempt,  and  some  important  ADL  guideline 
documents.  Thus,  the  emphasis  of  this  paper  is  not  on  specific  ADLs,  but  rather  on 
the  state  of  ADLs  as  a  whole. 

We  begin  by  presenting  some  background  information  to  define  an  ADL  and  place  It 
In  the  perspective  of  the  software  life  cycle.  We  then  examine  the  major  product 
surveys,  continue  by  discussing  the  standardisation  attempt  of  the  Institute  of 
Electrical  and  Electronics  Engineers  (IEEE),  and  finish  our  coverage  with  a  look  at 
some  major  ADL  guideline  reports.  We  conclude  by  summarising  major  findings  and 
pointing  to  the  future. 

2.  Background 

The  story  of  Adai  development  Is  certainly  well  known.  Those  wishing  details 
on  the  history  and  features  of  Ada  are  referred  to  Booch  (1).  Briefly,  Ada's 
development  was  Initiated  In  1975  by  the  US  Department  of  Defense  (DoO)  as  a  common 
high  order  language  for  real-time  embedded  computer  systems.  Tjday,  Ada  Is  a  mature 
language  with  wide  international  acceptance.  The  maturation  of  the  language  Is 
represented  by  the  fact  that  Ada  is  now  a  recognised  standard  by  the  US  DoD  (as  a 
military  standard  (MIL-STD),  the  American  National  Standards  Institute  (ANSI),  and 
the  International  Standards  Organisation  (ISO).  The  wide  acceptance  of  the  language 
Is  represented  both  by  the  standardisation  and  the  requirement  for  using  Ada  In  many 
national  and  International  policies.  There  is  official  policy  dictating  the  use  of 
Ada  for  certain  applications  in  the  United  States,  Canada,  the  United  Kingdom, 

West  Germany,  as  well  as  within  the  Commission  of  European  Communities  and  NATO. 

However,  application  of  Ada  to  avionics  is  still  relatively  new.  In  1984  the  US 
Air  Force  F-15  flew  trials  with  a  f ? Ight-control  computer  programmed  In  Ada.  Also 
In  1984,  Northop  claimed  Its  F-20  was  the  first  aircraft  to  fly  with  an  operational 
mission  computer  programmed  In  Ada. 
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6fv«n  the  maturity  of  the  language  Itself^  focus  has  shifted  to  the  larger  vieM  of 
the  system  life  cycle.  People  are  nON  more  concerned  with  how  to  Incorporate  Ada  In  the 
flow  from  project  concept  to  Implementation  and  beyond.  Below,  we  take  a  brief  look  at 
the  place  of  an  ADL  within  this  larger  context.  .. 

In  the  classic  view  of  the  software  system  life  cycle  there  are  the  following 
phases:  Analysis,  Design,  Implementation,  and  Maintenance  and  Modification.  This  Is 
often  referred  to  as  the  "waterfall**  life  cycle  model.  In  the  Analysis  Phase,  the 
system  requirements  are  Identified  and  documented.  The  analysis  documents  specify 
"what"  Is  to  be  done.  In  the  Design  Phase,  software  engineers  design  a  solution  that 
meets  the  requirements.  The  design  documents  consist  of  the  engineering  specification 
of  "how"  the  requirements  will  be  satisfied.  For  the  software  portion  of  a  system,  the 
Implementation  Phase  Is  where  the  working  code  Is  created.  Maintenance  and  Modification 
of  the  system  continue  as  mi nl -I terat Ions  of  the  overall  life  cycle  as  new  requirements 
emerge.  This  continues  until  the  system  Is  retired. 

There  are  many  techniques  available  to  address  each  of  these  life  cycle  phases. 

However,  traditionally  there  have  been  problems  In  smoothly  t rans I C ion ing  between 
phases.  Often  the  tools  and  techniques  appropriate  for  one  phase  may  not  be  useful  In 
another  phase.  A  program  design  language  CPDL)  Is  a  widely  used  tool  to  ease  the 
transition  between  the  Design  and  Implementation  Phases.  The  classic  reference  on 
PDLs  Is  Caine  and  Gordon  C2).  They  declare  that  the  purpose  of  PDL  Is  threefold:  to 
support  evaluation  of  a  design,  to  provide  guidance  to  Implementation,  and  to  serve  as 
a  tool  for  maintenance.  They  propose  that  use  of  a  PDL  results  In  Increased 
productivity  for  developers  and  Improved  system  quality. 

Initially,  PDLs  evolved  from  pseudocode.  In  form,  pseudocode  often  looked  like 
formalised  program  comments  which  used  the  three  basic  control  structures  (sequence, 
selection,  and  Iteration)  with  English  language  narrative  to  Indicate  the  operations 
performed.  The  designer  would  start  the  design  process  by  using  pseudocode  to  produce 
a  "rough  draft"  of  a  program.  Pseudocode  supported  the  design  principles  of  abstraction 
and  stepwise  refinement.  It  allowed  the  programmer  to  concentrate  on  high  level 
abstractions  and  to  avoid  getting  lost  In  the  details  of  a  programming  language. 

Furthermore,  the  rough  draft  could  be  successively  refined  until  a  working  program  was 
produced.  Thus,  pseudocode  was  truly  a  bridge  between  design  and  Implementation.  Today 
a  pseudocode  that  has  been  sufficiently  formalised  Is  usually  referred  to  as  a  PDL  and 
Is  a  standard  tool  of  the  software  engineer.  While  there  Is  no  universal  agreement  on 
all  POL  features,  most  contain  additional  design  Information  beyond  the  algorithmic 
Information  represented  by  pseudocode. 

Almost  from  Its  introduction,  Ada  has  been  hailed  as  a  design  language.  Indeed, 
there  are  many  features  that  tend  themselves  to  the  development  and  expression  of  design. 
These  features  Include  strong  support  for  abstraction  of  operations  and  data,  representat I  on 
of  concurrent  operation,  specification  of  generic  templates  for  subprograms,  and 
convenient  mechanisms  for  decision  deferral.  From  the  early  days  of  the  language,  Ada 
programs  were  designed  using  Ada  Itself  as  a  PDL,  and  today  the  term  Ada-based  PDL  or 
ADL  Is  commonplace.  While  there  Is  no  formally  established  definition  of  an  ADL,  one 
consistent  with  common  practice  Is  given  here.  An  Ada-based  Design  Language  may  be 
defined  as  a  textual,  procedural  design  language  that  closely  follows  Ada  syntax,  at 
least  supporting  the  detailed  design  phase,  and  usually  extending  the  Ada  language  with 
constructs  that  are  desirable  for  other  design  activities. 

The  state  of  practice  regarding  ADLs  for  Ada  system  development  has  followed  the 
same  rough  pattern  as  previous  software  engineering  practice.  Initially,  system 
developers  were  primarily  concerned  with  the  Implementation  Phase  of  the  life  cycle. 

Only  later  did  they  work  backwards  toward  the  start  of  the  life  cycle  to  define  a  full 
life  cycle  methodology.  While  Ada  designers  did  not  forget  the  lessons  of  the  past, 
some  of  the  non-t radl t lonal  features  of  Ada  have  called  for  new  approaches.  Thus, 
because  many  Ada  development  techniques  have  been  built  from  the  language  backwards. 

It  Is  not  well  established  how  you  should  produce  designs  to  account  for  Ada's  special 
features. 

While  the  emphasis  In  this  paper  Is  on  the  ADL,  many  Important  future  questions 
relate  to  the  methodology  preceding  ADL  In  the  life  cycle.  This  Issue  will  be 
briefly  discussed  at  the  end  of  the  paper.  We  will  continue  now  with  a  look  at  some 
of  the  major  AOL  studies. 

5.  ADL  Surveys 

The  major  leader  In  surveying  the  ADLs  was  the  US  Nava.  Avionics  Center.  In  1982, 
the  Naval  Avionics  Center  (NAC),  awarded  a  contract  to  SoftTech  to  conduct  a  survey  of 
existing  ADLs  C3).  The  survey  found  that  ADL  development  was  too  Irrmature  to  recommend 
any  standards.  They  found  only  four  true  ADLs  In  use  and  fovtnd  no  consensus  among  them. 

The  report  concluded  that,  while  standardisation  was  not  appropriate,  the  Navy  could 
promote  the  use  of  ADLs  and  the  development  of  guidelines. 

In  198if  tha  NAC  recognised  the  Increasing  number  of  ADL  efforts  and  reinitiated 
Its  survey  project  with  a  contract  to  Computer  Technology  Associates  (4).  The  survey 


I2'3 

team  collected  initial  Information  about  28  different  PDLs.  After  Initial  analysis^  the 
team  determined  that  seven  were  In  early  developmental  stages  and  were  not  appropriate 
for  detailed  evaluation.  Five  more  were  not  sufficiently  Ada-Abased.  This  left  sixteen 
true  ADLs  that  were  eventually  examined  In  detail. 

To  allow  detailed  comparison  of  the  AOLs,  the  team  used  four  major  categories  of 
characteristics:  syntactic  and  stnantlc  character 1 st Ics,  automated  support  characteristics^ 
methodology  characteristics,  and  documentation  character  I st Ics .  In  examining  syntactic 
and  semantic  characteristics,  an  important  consideration  was  how  close  the  AOL  resembled 
Ada.  Was  It  standard  Ada,  or  was  It  a  superset  or  a  subset  of  Ada?  If  it  were  a 
superset  of  Ada,  what  language  extensions  were  chosen?  Regarding  automated  support, 
it  was  clear  that  such  tools  were  essential  for  complex  system  development.  Thus,  the 
survey  examined  environmental  support  for  each  ADL.  As  we  have  already  mentioned,  the 
ADL  should  not  stand  In  isolation,  but  should  be  one  tool  within  a  life  cycle  methodology. 
It  was  expected  that  the  AOLs  would  support  the  design  phase,  but  some  ADLs  offered 
support  beyond  this.  Representat Ion  of  this  supplemental  support  information  was  an 
obvious  point  of  Interest  for  the  study.  Finally,  documentation  support  was  examined. 

They  felt  that  It  was  necessary  to  have  both  tutorial  and  reference  guides.  Case 
studies,  style  guides,  and  other  classes  of  documentation  were  also  known  to  be 
Important.  Given  this  evaluation  framework  the  sixteen  ADLs  were  examined  and  compared 
In  detail.  We  summarise  the  major  findings  below. 

On  a  high  level,  the  AOLs  showed  some  convergence  and  agreement  on  Issues  of  broad 
form.  However,  on  a  detailed  level  there  was  considerable  divergence  in  Implementation. 
Many  of  the  differences  were  seen  to  be  caused  by  open  questions  that  lacked  a 
generally  accepted  solution.  Differences  In  syntax  were  often  the  result  of  different 
approaches  to  life  cycle  support.  For  example,  all  ADLs  supported  both  preliminary  and 
detailed  design  activities.  However,  «rht1e  most  ADLs  extended  the  language  to  support 
other  phases,  there  was  little  agreement  on  which  kinds  of  supplemental  Information  to 
represent.  For  example,  some  concentrated  on  Interface  specifications  and  others 
addressed  requirements  tracing  and  design  constraints.  There  was  considerable 
divergence  In  details. 

The  areas  of  automated  support  and  methodology  support  were  somewhat  intertwined. 
There  was  a  trend  toward  more  automated  tools,  but  few  plans  to  automate  such  life 
cycle  support  activities  as  requirements  tracking  or  design  analysis.  This  seemed  to 
be  because  many  developers  desired  methodology  Independence  for  their  ADl.  The 
survey  authors  observed  that  methodological  Independence  would  have  to  be  abandoned 
before  comprehensive  automated  support  tools  could  be  developed. 

The  survey  concluded  that  ADL  efforts  to  this  point  concentrated  mainly  on 
syntax  and  semantics  issues.  A  major  onanswarad  ouastlon  was  how  to  fit  the  ADL  Into 
the  larger  context  of  the  life  cycle.  The  authors  did  not  find  any  one  Implementation 
or  group  of  Implementations  as  clearly  superior.  Most  had  Important  weaknesses  as 
well  as  strengths.  They  concluded  that  careful  monitoring  of  new  developments  was 
Important . 

Since  the  1984  survey,  no  one  has  produced  a  similar,  comprehensive  report. 

Today,  the  most  appropriate  place  to  obtain  current  ADL  Information  Is  In  the 
Association  for  Computing  Machinery  (ACM)  publication  "Ada  Letters".  Each  month 
Ada  Letters  publishes  an  "AOL  Developer's  Matrix".  The  matrix  Is  actually  a  table 
listing  all  known  AOLs  divided  Into  two  categories,  ADL  products  that  are 
"Commercially  Available"  and  "Other".  Entries  In  the  "Other"  category  are  usually 
ADLs  that  are  for  Internal  company  use  only,  are  products  under  development,  or 
are  government  reports  In  the  public  domain.  The  information  in  the  table  consists 
of  the  organisation's  point  of  contact,  comparison  of  the  ADL  to  Ada,  available 
support  tools,  and  product  availability.  In  the  November/December  1987  Issue  of 
"Ada  Letters"  there  were  fifteen  convnerlcal ly  available  ADLs  and  thirteen  other 
ADLs  (5).  This  represents  nearly  a  doubling  of  ADLs  from  the  198^  NAC  report. 

With  so  many  ADLs  currently  In  use,  it  might  be  expected  thnt  some 
standardisation  would  have  recently  taken  place.  We  address  this  effort  In  the 
next  section. 

4.  IEEE  Standardisation  Attempt 

In  May  1982,  the  Instltutefor  Electrical  and  Electronics  Engineers  (IEEE) 
fortnad  a  working  group  to  examine  the  Issue  of  possible  ADL  standard  I  sat  Ion.  Even 
after  several  years  of  work  on  ADLs  within  government  and  Industry  It  became 
apparent  to  the  group  that  the  state  of  practice  was  still  too  Immature  to  specify 
a  standard.  Instead  the  group  published  a  "Recommended  Practice"  document  In 
January  1987  (6).  The  rather  brief  nature  of  the  document  (about  pages  of 
main  body)  demonstrated  Just  how  far  away  ADL  standards  still  were.  The  report  is 
summarised  below. 

With  regard  to  scope.  It  Is  Instructive  to  see  that  the  report  explicitly  does 
not  specify:  a  single  AOL  syntax,  a  specific  methodology,  or  the  method  of 
processing  the  ADL.  What  the  report  does  specify  Is  high  level  characteristics  of 
an  ADL  with  regard  to  methodology  support,  design  support,  supplemental  support, 
and  the  relationship  to  Ada.  Obviously,  all  these  topics  are  covered  only  briefly. 
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For  example.  In  the  area  of  general  methodology  support,  the  report  recommends  support 
for  the  principles  of  abstraction,  decomposition,  information  hiding,  stepwise  refinement 
and  modularity,  devoting  only  a  few  sentences  to  each  topic. 

One  potentially  controversial  recommendation  Is  that  an  ADL  should  conform 
syntact leal  1 y  and  semantically  to  ANSl/MIL^STD  Ada.  Extensions  to  the  would  language 
consist  of  comments,  possibly  with  special  sentinel  characters  to  alert  any  particular 
AOL  preprocessor  that  might  be  used.  This  Is  possibly  controversial  because  some  believe 
ADLs  should  extend  the  language  and  require  that  the  ADL  be  processed  by  a  preprocessor 
before  the  AOL  would  become  compilable  Ada  code.  However,  we  believe  Che  IEEE  position 
on  this  point  Is  correct  If  we  are  ever  to  converge  on  a  standard. 

Further  summarisation  here  Is  unnecessary  due  to  the  brevity  of  the  original 
document.  What  Is  most  Important  about  the  report  Is  that  a  highly  qualified  committee 
was  unable  to  come  close  to  defining  a  standard.  This  Is  a  clear  signal  that  general 
guidelines  are  very  Important  for  large  governmental  organisations,  like  NATO,  who  are 
trying  to  put  some  limits  on  the  dialects  of  systems  they  will  have  to  maintain. 

3.  AOL  Guideline  Documents 

As  was  mentioned,  many  national  policies  dictate  the  use  of  Ada  for  certain 
applications.  Even  further,  use  of  an  AOL  Is  required  by  some  major  organisations  such 
as  the  US  Army  and  Transport  Canada.  Other  major  organisations  have  required  use  of  an 
ADL  for  specific  projects.  Given  the  lack  of  a  credible  standard  and  only  high  level 
convergence  among  ADLs,  guidelines  become  essential  for  policy  Implementors.  They  are 
necessary  to  Insure  consistent  and  proper  professional  practices  among  contractors  and 
to  place  at  least  rough  bounds  on  the  different  ADLs  to  be  maintained.  Below  we  will 
discuss  the  major  reports  produced  for  Transport  Canada  and  the  US  Naval  Avionics 
Center.  While  we  recognise  the  contribution  of  ftamtec  to  the  US  Army  (7),  we  believe 
the  other  two  reports  are  more  generally  applicable. 

5.1  Transport  Canada  effort 

One  of  the  early  efforts  to  define  a  set  of  guidelines  was  developed  by  PRIOR 
Data  Sciences  for  Transport  Canada,  the  Canadian  federal  transportat Ion  regulation 
agency.  The  original  report  was  published  In  1984  and  was  updated  In  1987  (8). 

In  this  section  we  discuss  the  major  features  of  the  report. 

The  purpose  of  the  report  Is  to  provide  project  managers  a  reference  to  assist 
In  the  evaluation  of  contractor  proposals  for  new  software  systems.  As  mentioned, 
policy  requires  the  use  of  an  AOL  within  this  agency.  The  document  consists  of 
three  main  sections:  an  overview  of  the  POL  concept,  an  overview  of  the  ADL  concept, 
and  AOL  evaluation  procedures.  The  appendices  of  the  report  Include  a  complete 
design  example,  a  discussion  of  design  decision  deferral,  guidelines  for  Implementations 
In  languages  other  than  Ada,  and  an  AOL  evaluation  checklist. 

One  of  the  major  contributions  of  this  report  Is  the  Identification  of  software 
development  activities  that  can  be  supported  by  an  ADL  and  how  the  ADL  might  support 
them.  The  guidelines  Identify  these  activities  as  requiring  differing  support  from 
an  AOL:  design  engineering,  quality  assurance,  project  management,  independent 
verification,  and  customer  acceptance.  These  classes  of  activities  form  the  basis  for 
choosing  ADL  features,  which  are  then  discussed  on  a  high  level. 

Another  Important  contribution  Is  the  appendix  Including  a  detailed  design 
example  for  an  organisational  membership  list  management  system.  This  demonstration 
of  an  actual  AOL  design  Includes  almost  90  pages  of  ADL  listing.  The  automated  support 
tools  utilized  were  an  Ada  compiler  and  an  ADL  tool.  They  discuss  the  features  of  the 
ADL  tool  which  Includes,  among  other  things,  several  cross  reference  generators,  a  data 
dictionary,  and  a  requirements  tracer, 

Perhaps  the  most  widely  recognised  and  popular  section  of  the  report  Is  the 
ADL  Evaluation  Checklist.  This  checklist  provides  18  pages  of  evaluation  questions 
to  apply  to  a  potential  ADL.  It  Is  divided  Into  the  following  categories:  support 
for  the  development  activities,  support  for  software  engineering,  actual  features 
of  the  ADL,  and  tool  support.  The  questions  are  phrased  such  as  that  a  "yes"  answer 
Is  desirable  and  provide  a  good  basis  to  separate  the  good  ADLs  from  the 
questionable. 

In  general,  these  guidelines  enjoy  a  good  reputation  and  have  served  as  a  model 
for  many  other  efforts.  They  have  been  used  successfully  In  several  projects  C9). 
However,  as  with  all  general  guidelines,  the  success  of  any  given  ADL  project  Is 
dependent  on  the  skill  of  the  people  Involved. 

5.2  The  Software  Productivity  Solutions  Guidelines 

In  1985  the  US  Naval  Avionics  Center  once  again  took  a  leadership  role  in  the 
ADL  arena  by  letting  a  contract  for  the  production  of  ADL  guidelines  to  be  compatible 
with  the  US  OOD-STD-2167.  This  standard  is  the  US  DoO  standard  for  development  of 
defense  software  systems.  In  January  1987  the  contractor.  Software  Productivity 
Solutions  (SPS),  Issued  their  raport  (10).  Tha  main  body  of  tha  report  tackles  the 
ADL  question  by  a  series  of  propositions  and  resolutions  Identifying  the  major 
Issues  to  define  an  ADL's  scope.  Included  as  major  appendices  are  ADL  development 
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guidelines^  acquisition  management  guidelines,  and  guidelines  for  tool  sets.  Generally, 
the  report  Is  compatible  with  the  Transport  Canada  Guidelines.  This  report  was  able  to 
extend  and  formalise  some  of  the  recommendations  and  discussions  Initiated  in  the 
Canadian  report.  Below  we  discuss  the  major  features  and  contributions. 

The  main  body  of  the  report  addresses  propositions  and  states  resolutions  aoout  the 
scope  of  an  AOL  in  the  following  main  categories:  support  for  engineering  activities, 
support  for  management  activities,  support  for  quality  assurance  activities,  automated 
support  for  the  ADL,  and  the  relationship  between  Ada  and  an  ADL.  The  verification  and 
acceptance  activities  used  In  the  Canadian  report  are  generally  subsumed  among  the 
categories  here. 

The  AOL  development  guidelines  appendix  are  more  detailed  than  any  guidelines 
produced  thus  far.  They  focus  In  particular  on  the  support  requirements  for  engineering 
design.  Using  these  as  a  focus,  they  recommend  specific  ADL  syntax  and  features  using 
an  approach  that  specifies  both  kernel  and  optional  ADL  features.  Kernel  features  are 
those  that  should  be  supported  by  all  AOLs  with  options  chosen  to  meet  the  special  needs 
of  a  given  project.  The  main  contribution  to  previously  suggested  ADL  syntax  was 
support  for  the  DoD>2167  "static  structures"  model  for  software  systems.  The  static 
structure  of  a  system  Is  a  way  of  specifying  an  arbitrarily  complex  hierarchy  of 
software.  Given  the  size  of  the  DoD  market,  many  International  vendors  produce  products 
that  are  compatible  with  the  standard. 

While  the  acquisition  management  guidelines  are  particularly  useful  to  those  using  a 
US  OoD  system  acquisition  model,  they  can  be  tailored  to  other  models.  In  the 
guidance  on  procurement,  there  are  suggestions  for  the  request  for  proposals  and 
proposal  evaluation.  In  the  guidance  for  contract  monitoring  there  are  suggestions  for 
technical  reviews,  verification  and  audits. 

While  the  report  has  Initially  attracted  much  Interest,  there  Is  some  controversy  on 
the  mapping  of  Ada  constructs  to  the  2167  model.  This  is  not  necessarily  a  criticism 
of  these  guidelines  but  rather  concern  by  Ada  designers  of  mapping  to  the  static 
structure  model  Itself.  Those  Interested  In  more  details  are  referred  to  (lO  and  (12). 

6.  Conclusions 

In  this  paper  we  have  discussed  some  of  the  more  important  work  evaluating  the  state 
of  ADL  practice  today.  We  have  seen  that  there  Is  high  level  convergence  of 
philosophy  on  many  Issues,  but  there  are  many  open  questions  on  the  detailed  level. 

This  has  resulted  In  abandoning  attempts  to  standardise  and  concentrating  on  providing 
general  guidelines.  Most  people  seem  to  agree  that  guidelines  for  general  usage  must 
recognise  the  unique  requirements  of  each  project  and  choose  the  ADL  features 
accordingly.  This  points  In  the  direction  of  the  "kernel  with  options"  philosophy 
of  the  SPS  report. 

A  potentially  fruitful  area  for  further  work  Is  the  definition  of  guidelines  for 
what  could  be  a  set  of  "standard"  options.  This  Is  alluded  to  In  the  SPS  report,  but 
not  developed  In  detail.  For  Instance,  some  specific  projects  might  have  a  need  for 
an  ADL  that  would  Incorporate  database  aspects.  Since  not  all  projects  would  require 
this,  database  specific  AOL  features  should  be  options  and  not  part  of  the  kernel. 
However,  the  requirement  to  develop  systems  with  database  aspects  would  occur  often 
enough  to  call  for  common  guidelines  for  this  application.  If  you  extend  this  concept 
to  other  common  requirements,  you  could  develop  a  standard  set  of  AOL  feature 
"modules".  With  enough  refinement  and  use  these  could  provide  the  basis  for  a  new 
standard  1  sat  Ion  effort . 

Unquestionably  the  major  area  for  future  work  Is  in  the  area  of  methodologies. 

This  problem  Is  not  unique  to  Ada  and  ADLs,  but  some  of  the  opportunities  presented  by 
the  language  are  not  fully  integrated  Into  a  generally  accepted  life  cylce  approach. 

Many  widely  recognised  Ada  development  methodologies  have  limitations  or  rely  on 
above  average  software  eng  I  near  I ng  sk 1 1 1 s  for  their  effective  ure.  In  order  to 
promote  good  system  development  by  the  average  software  engineer,  we  need  simple, 
well  defined  .methodologies  backed  up  by  substantial  automated  support.  As  methodologies 
evolve,  the  role  of  ADL  as  a  tool  may  also  evolve,  but  It  seems  apparent  that  AOLs 
will  be  a  major  tool  for  Ada  system  development  for  the  foreseeable  future. 
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SOMMOr 

Future  avionic*  ayatae*  will  comlat  of  diatrituted  fault-tolerant  ardvltectures.  Ihe  cperational 
flight  software  will  be  written  In  the  Ada  pcograaning  language  and  use  a  distributed  operating  systaai. 
Developing  and  aoaintaining  thi*  aoftware  require*  new  and  innovative  debugging  techniques  to  reduce  cost, 
tiae«  and  ocep>leicity«  This  paper  will  describe  two  specific  techniquee.  Iheae  are  dynnic  trace  buffers 
and  floftwaxe  Bullt-m-StqppartHPUnctions  (BZ9*).  First  the  need  for  new  appacache*  to  debugging  distributed 
Ada  ooftware  1*  addresead.  Then  the  laplanantation  of  of  the  tedlidque*  is  presented.  Ihe  Fvicnics 
Laboratory  is  the  only  ocganization  to  successfully  deaonstrate  both  techniques  with  HIL-SlD-nsOA  oonputers. 
Cbeervation*  and  far  using  these  techniques  %iill  be  reported. 

PRBPKE 

There  axe  two  new  advances  in  technology  that  «flll  influancsa  the  develcpsent  of  avionics  software. 

Ona  is  the  introduction  of  the  Ada  prograsning  language.  The  Oepartaent  of  Defense  (DoD)  has  mwnrttfarl  the 
Ada  prograsmlng  language  for  all  mission  crltlcai  software.  Sinoe  Ada  csontains  seny  advanced  features  not 
found  in  other  languagee  used  in  avionics  systOM#  their  iiqpact  on  avionics  software  dafaugging  and 
Integration  needs  to  be  known,  the  eeoond  advance  is  the  use  of  distributed  foult  tolerant  avionics 
architectures.  The  new  avionics  systese  will  place  additional  deamnds  on  the  aoftware  developer, 
integrator,  and  ealntainer.  Tb  support  theee  advances  in  tednology,  new  software  debugging  appsoaches 
are  requited.  The  use  of  Built-Xn-St^port  Functions  and  trace  buffers  axe  two  such  approaches. 

1.  ACA  TASKING 

mth  the  introduction  of  Ada,  several  new  feature*  are  available  to  the  pmgmoer.  Fbr  exaeiple,  the 
high-level  constnxt  tm^oing  cm  be  used  fee:  concurrent  progmning.  In  the  past  concurrent  progrmdng 
relied  on  Icie’lsnml  constructs  like  eemphcKes.  SoBBphores  will  s^U  be  used  and  can  be  ispleaiented  %Ath 
Ada.  ikiderstandlng  the  ioplicationa  of  debugging  software  that  uses  talcing  requires  knowing  aonelhijng 
about  how  Ada  tasking  works. 

flnmmnication  and  synchronization  between  tasks  are  handled  by  entry  calls  and  accept  Btataoente. 

Itien  an  entry  has  been  called  and  a  oorxesponding  aooept  statement  has  been  reached,  the  sequence  of 
statenents,  if  any,  of  the  aooept  stateeent  is  executed  by  the  called  task  hhile  the  calling  task  xenalns 
au^jended) .  This  interaction  is  celled  a  lendezwus.  Thereafter,  calling  taak  and  the  task  owning  the 
entry  continue  their  execution  in  parallel,  fl] 

It*  8  ii^ortant  to  note  that  if  several  tasks  call  the  saae  entry  before  a  corresponding  accept 
etateeent  is  reached,  the  calls  axe  queued.  There  is  one  queue  associated  with  each  entry.  &ch  execution 
of  an  accept  statoMnt  reneves  one  call  from  the  queue.  The  caiig  are  processed  in  order  of  arrival,  fl] 
Ddaugging  Ada  tasks  requires  knowledge  of  %dien  the  rendezvouses  occur  in  tdtat  order.  Therefore,  the 
tndeteiminacy  of  Ada  tasking  requires  monitoring  techniques  that  can  support  noiprcfaabilistic  code. 

The  delay  statement  is  frequently  used  with  Ada  tasking.  The  execution  of  a  delay  statoaent  suspends 
further  execution  of  the  task  that  calls  the  statesent  for  at  least  the  duratiem  specified.  A  delay 
statenent  with  a  negative  value  is  equivalent  to  a  del^  with  a  zero  value.  [2]  Since  the  del^  is  minimal, 
errors  could  occur  if  softwere  is  relying  on  precise  tisdng. 

2.  DfNNQC  AimCXnCR  OF  VARIMUS 

The  dynandc  ailocation  of  Ada  variables  also  presents  new  challenges  for  debugging.  Local  variable 
addresses  are  detennijied  by  evlding  an  offset  to  the  stack.  Thus,  the  actual  addresses  are  wdenown  prior 
to  execution.  This  ocsplicates  the  monitoring  of  variables  in  re^-time,  especially  in  a  foult-tolerant 
and  reccnfiguxable  envirerments. 

current  softwere  test  eqaipwit  cen  support  statically  allocated  variables.  Ada's  variables  can  be 
monitored  if  th^  are  declared  globally.  Bewever,  if  the  Ada  softwere  is  dynnically  allocated  to 
different  address  states,  then  even  these  variables  cannot  be  monitored.  Cbviously  the  capability  to 
BEnitor  Ada  variables  is  needed, 

3.  SCRIMS  FMSflVTaBOICy 

Softwere  fault-tolerancy  also  requires  new  debugging  appeoeches  for  de^«lc(lBent  and  integration. 

Fhture  avionics  systsss  will  have  saae  type  of  softwiixe  fault-tolerancy.  For  exasple,  the  RAVE  PIUAR 
ipecifiCBtion  calls  for  the  use  of  dynasde  error  handling  techniques.  These  techniques  involve  the  use  of 
operational  software  code  to  detect,  confine,  end  correct  software  data  and  tisdng  errors  during  software 
operation.  [3] 
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Vtarl^ing  that  fault-tolaraiit  acftame  aorks  ooireetly  la  a  tn^lac  effcst.  The  softMere  test 
injiilianil  Hill  i»ad  to  trace  the  eeecuticn  of  the  avionics  paogm  in  real-tiae.  Hlth  a  distributed 
systeai  the  paograa  tracing  mist  take  place  for  aultiple  [rniji  issi  naming  on  aultiple  processors.  With  the 
softs  are  runiing  at  Very  High  S^eed  Integrated  Circuit  (VRSIC)  npeeda  this  is  bejtaid  the  cagsabillty  of 
current  dehigjing  equipment.  VBSIC  aleo  preaanta  a  piveioel  signal  acoees  (noblem. 

4.  BISP 

current  real-tiae  softeere  ataiitcring  technology  does  not  aifpxt  dynosic  acnory /processor  allocation. 
M  above,  future  avionice  aysteaa  tdll  heve  theae  dsaracteristics.  The  BISP  concept  %«s  prqpoeed 

as  a  aclutlcn  to  this  pnUbleB  by  Ouane  O.  Hague  Jr.  •  an  engineer  at  the  tttlted  states  Air  COroe  Mright 
Jmronautlcal  labocatories'  kvionics  laboiatKy.  M:.  Begoa  ptcpneod  the  creation  of  a  epecial  class  of 
software  hook  instructions  that  are  adiedded  into  tirn  application  and/or  operating  systn  software.  The 
BISP  iMtmctione  would  transfer  software  hook  infonsitton  to  a  apeeialited  BISP  integrated  circuit 
resident  on  the  processor  -oduie  that  functions  as  an  output  port  to  the  external  support  equivalent.  TO 
the  pKOceasor/aystaa,  eoancuticn  of  a  BISP  instruction  would  be  equivalent  to  the  execution  of  a  ’NO-CP* 
instruction. 

There  are  three  BIS'  instructions  that  would  provide  the  needad  debugging  sipport  for  aultiprocessor/ 
Ms  avionics  architectures.  These  instructions  are  the  Dctemal  Pleg  (XPUS) ,  Bctemal  Flag  Heglster  IXap 
(XFUat) ,  and  the  Bctemal  Traoe  CCTK) . 

The  XFIC  instruction  outputs  an  isiique  flog  value  to  the  aperlaUxed  BISP  output  port,  thus  aoking 
the  value  available  to  the  external  sigport  equivaent.  This  parwides  the  capability  for  tracing  code 
eicecutlan.  By  tiae  tagging  the  flag  output  software  perforsanoe  can  be  seasumd  and  timing  and  intermittent 
errors  can  be  located. 

The  XFUSt  instruction  outputs  an  imlque  flag  value  and  the  contents  of  a  register  to  the  BI^  output 
poart.  This  provides  the  capability  to  nociitor  stack  based  variables.  Software  test  equivalent  can  use  the 
value  of  the  staiSc  pointer  to  add  with  the  aoapiler  generated  relative  address  of  the  prograaa  variable  tc 
determine  the  absolute  address  for  monlborlng. 

The  xnc  instruction  triggers  the  test  equivaent  to  take  a  limited  size  snap-shot  of  sequential 
ptooesaor  internal  bus  activity  such  as  instruction  at  data  reads  and/or  tirites. 

BISP  instructlans  are  inserted  at  points  of  interest  in  the  Ada  software.  Ftir  exasple  in  Ada  tasks, 
proaedures,  and  eocoeption  handlers.  Other  areas  oonaist  of  those  sections  of  software  that  need  performance 
tuning.  XFUS  Instructlcns  can  be  inserted  by  the  ooepller  as  pert  of  the  calling  ccanwntion  used  for 
context  changes.  Dsing  the  BISP  instructions  requires  no  change  to  Ada  (MI1/-HII>-1B1SM  or  HIL-9n)-1750A. 

5.  BISP  OHUBBnxnCH 

The  System  Bvaluation  Branch  of  the  Avianlca  Uboratory  initiated  an  in-house  effort  in  1986  for  full 
BISP  proof-of-oonoept  for  the  iah-Sn>-1750A  ooaputer.  The  instructions  were  iaplenentad  by  using  the 
optional  user  defined  Built-In-PUncticn  (BIP)  instruction  in  the  NII,-sn>-1750A  mstructlcn  Set 
Architecture.  The  BIP  inetructicn  invokes  special  operations  defined  by  the  user.  |3]  The  XPIC  and  XPLGH 
instructions  ware  danonetrated  with  Ada  tuning  on  a  Fairchild  F94S0  17S0A  ocaputer  in  the  fall  of  1987. 
Qurrently  a  aoftwere  perfotmanoe  Hmitor  and  OontroUer  dWC)  that  will  uae  the  BI7  for  monitoring  and 
debugging  distribubed  Ada  software  rutming  on  17S0A  oceputera  is  being  designed. 

The  P9450  1750A  cpu  wee  aelected  because  it  supports  the  BIP  inetructicn.  The  F9450  lapleBents  the 
BIP  as  a  three  word  instructlan.  It  treats  the  instruction  as  a  oo-prooesaor  escape  «4iere  the  BIP 
inetructicn  writes  its  extenslan  field  to  a  dedicated  XIO  address.  The  iaplanentatlcn  of  each  of  the  BISP 
instructlans  fbr  the  P9450  is  shown  in  figure  1. 

There  are  two  approachaa  to  using  BISP  with  Ada  software.  Oie  approach  requlree  the  Ada  coaqiller 
having  aafebiUty  for  Insartlng  machins  coda  inline,  and  the  aaw.iitiUir  allcwing  for  the  BIP  instruction  or 
the  capability  for  defining  an  instruction.  This  approach  requires  pragie  in-line  and  pragia  interface 
fear  Including  merhlm  code  with  the  Ada  aoftwore.  The  other  approach  involve  the  use  of  the  package 
MKXONEJXOB.  An  exmiple  of  each  approach  is  ahewn  in  figures  2  and  3. 

Several  emperiments  using  the  BIS  with  Ada  were  oonducted.  Ctie  experiment  involved  using  the  XFTC 
instruction  for  nonltorlng  a  ptugraei  siadlar  to  what  is  ahown  in  figure  2.  Ikch  Ada  task  was  to  perfoim 
an  activity  at  a  regular  interval.  TO  verify  that  indeed  the  tasks  were  operating  within  the  given  time 
constraints  ths  XPUS  instruction  was  used.  Oalng  a  logic  analyser  to  monitor  the  BI7  port,  the  time 
Irninrn  each  identical  flag  was  obtained.  Badi  task  waa  verified  to  execute  within  its  allotted  aecunt  as 
specified  in  ths  prcgraei. 

6.  DTSBOBlIlTa)  (JPB«tnMS  SXH19B 

Application  software  written  for  next  generatlcn  svimlcs  systesm  wil.  use  an  eehwiVled  real-time 
distributed  operating  syateei.  This  operating  systoa  provides  the  control  mechaniaBn  and  ayplicetian 
aervloea  within  the  aultiprooesaor  system.  Ths  ptooeeaee  that  meke  qp  the  application  eoftwere  are 
achedulsd  by  the  operating  eystsm  of  the  avionice  system. 

riiiijiimeiliiij  a  distributed  erehitseture  is  not  a  trivial  activity.  Tlie  ptobleme  of  race  conditions, 
dsadlocfc,  and  prooein  starvation  occur  during  the  deimlopamnt  of  the  avionics  software,  Tb  assist  the 
prograemer  the  distributed  operating  system  can  employ  trace  buffers. 
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7.  TRACE  fiCffFHtS 

An  Mb  distributed  Rexnel  C|)erating  Systcn  (KOS)  vaa  develcped  and  delivered  to  the  Asricnics  Laboratory 
by  Nteting^iouse  Defense  and  Elec±ronics  Oenter  for  the  V8SIC  Avionic  Modular  Processor  (VAKP)  architecture. 
Ihe  KC6  is  currently  being  used  with  the  Bhginecjring  Develcpnent  Model  (SM)  of  the  VAIP.  The  ECM  is  a 
nultiprooessor  sysben  consisting  of  three  17S0A  cpus,  a  1553B  board,  and  a  bulk  nesDiy  card  connected  to  a 
parallel  internal  (PI)  bus. 

Tb  assist  in  debugging  of  the  application  software  the  RC6  eoploye  two  trace  buffers  -  an  Active 
Trace  Buffer  and  a  Call  Trace  Buffer.  The  buffers  are  optioMl,  enabled  by  settii^  a  paraneter  in  the 
KGS's  definition  file.  Both  buffers  are  circular  with  their  aise  specified  in  the  definition  file. 

The  Active  Trace  Buffer  is  a  <±ronoLogy  of  the  active  process  in  the  processor.  [4]  The  active 
process  infonoation  is  entered  into  the  buffer  by  the  KOS.  This  infonnaticn  is  hex  data  that  indicates 
what  KOS  sendees  were  called. 

Usually  Infoanation  is  needed  on  all  the  procesees  that  were  actiue  in  the  system.  The  call  trace 
buffer  is  cenprised  of  4-^rd  entries,  tdiere  each  entry  contains  infonnaticn  about  calls  made  by  the 
application  to  the  KOS  or  tdwn  PI-BUS  nessageti  are  received  telling  the  IK3S  to  signal  a  seoaphore /event.  [4] 

A  sanple  duip  and  explanation  is  given  in  figure  4. 

Fran  experiences  in  the  laboratory,  the  trace  buffers  reduce  debugging  tine.  They  are  extremely 
helpful  in  detemining  if  the  system  is  correctly  initialised.  The  porogroaBer  can  verify  that  all 
processes  are  defined  and  the  software  starts  its  execution  correctly.  Tine  is  also  saved  by  avoiding  the 
work  of  going  throi^  listings  and  link  imps  to  determine  what  process  was  the  last  one  active. 

8.  OCMOJUSIOI 


Debugging  distributed  Ada  avionics  software  can  be  a  ocBplicated  jcb.  The  BI9  is  the  lowest  cost, 
least  coiplex  approach  to  real-time  software  debugging  and  monitoring.  The  Avionics  Laboratory  has  ^lown 
that  BISF  instructions  can  be  iaplenented  with  Ada  and  the  MIl/-9n)-17S0A  instruction  set  architecture. 

Using  trace  buffers  is  another  low  cost  ipproach.  Their  usehUness  has  been  dononstrated  %ri.th  a  distributed 
operating  system  running  on  an  architecture  similar  to  %JhBt  will  be  used  by  future  avionics  systmns. 

9.  ROTSBNCES 
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Avionics  laboratory;  JAN  1987;  plS 
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XTRC 


S  •  TRACE  SELECT 


XFLGR 


BIT  8  CONTAINS  0  BIT  9  CONTAINS  1 


i 


i 


XFLG 

BIT  8  CONTAINS  0  BIT  9  CONTAINS  1 
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PORT 


FLAG 

0  16 


j  NOT  USED 

[ _ 

0  15 


FIGUPE  1 


with  5YS71M;  use  SYST®!?  package  BISF^SUPPCWT  is 
prooedure  XFICO; 

pra^na  interface  (ASSEUBUP,  XFIiSO); 
pra^na  inline; 

procedure  XFIGl; 

pra^iB  interface XPLGl); 
pragm  inline; 

procedure  XFLG2; 

pra^na  interface  (ASSEWUTif  XFI£2); 
pra^na  inline; 


end  BI^_SUFPCfiT; 

This  package  is  included  with  the  Ada  applications  software 

with  BISF  SUFPCRT; 
use  BISB  %FPGRr; 
with 

use  SY9IB4; 
with  CKBBML} 
use  CAUNMR; 
pcooedute  AVICMICSJIASKS 


I 


i 
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task  type  TASKOJTYFE  is 
entry 

end  TASKOJTYPE? 

task  type  TkSKlJIYFE  is 
ei^ry  START; 
end  TASKIJIYPE; 


additional  task  type  declarations 


TASKO  :  TASKOjryPE; 
TASKl  :  TASKljryPE; 


additional  task  declarations 


task  body  TASKOJTVPE  is 

NEXr_nHWriCN_TIME  :  CAIMIAR.TIME? 

CYCLEJXJRATICN  :  constant  :*  0.004; 

begin 

accept  START  do 

—  MAIN  PROGRAM  IS  NOW  WAITING  FOR  RENDEZVOUS  CCMPI£TICN 
null; 
end  SEART; 


NBCr_ITERATICN_TIME  :=  CLOO?; 


loop 

— BISF  XFDSO; 

— Perfozn  avionics  activity 


NB(T_ITERATI®TTME  :*  NEXT_H®RAT1CN  TIME  +  CYa£_DURAnCN; 
delay  fNEXr_riERATlCN_TTME  -  CLOCK) ;  ” 
end  loop;  ” 

end  TOSKOjnrPE; 

task  body  TASK1_TYPE  is 

NBCr_rra«lTCN_TIME  :  CAIZNDAR.TIME; 

CyCI£_DURATICK  :  constant  :«  0.008; 

—  Activity  performed  once  every  8  msec. 


begin 

accept  START  do 

—  MAIN  PROGRW  IS  NOW  WATTIMS  PCR  RQ©EZV0US  CCMPUmCN 
null; 

end  START; 


NE3Cr_riT3WCnCNjnME  ;=  CLOCK; 
loop 

—BISF  XFU31; 

—Perform  avionics  activity 


NBa*_rrE3WriON_TIME  ;=  NEOT^ITERMlCNjnME  +  CyCI£_DURATlCN; 
delay  (NEXT_nnwrtQN_TIME  -  CLOCK); 
end  loop; 

end  TASKl  TYPE; 
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Additional  ‘Risk  bodies 


begin  lASK  EXAMPLE 

— AUi  TA^  ARE  SUSPBI3B>  KT  ACCEPT  SOART,  AM) 

TASKO.SIAFT} 

TASKl.SEART; 


Additional  task  starts 


end  AVICNICS  TASKS; 


Figure  2 


with  ^sten;  use  System; 
package  Machine^Oode  Is 
BITS  :  oonstant  1; 

tCRD  :  constant  16; 

type  Cpoode  is  (BIF); 
for  C|xx}de*SIZE  use  8*BITS; 
for  OFQSE  use  (16«4F«) ; 
type  MAtCKinVJRFE  is  rar^  0..3; 
for  MMClATQiVjryFE'SIZE  use  2«BITS; 
type  PORrjrype  is  range  0..3; 
for  PCRTjryPE'SIZE  use  3*BrrS; 
type  RB5ZSTSMYFE  is  range  0.  .15; 
for  RBGXSTEEjnPE'SIZE  use  4*BnS; 
type  FUGjryPE  is  range  0..6S535; 


for  FlASjfypE'SIZE 

use  ].6*BITS; 

type  BISF  is 

record 

lESmXTICN 

:  CPOGDE; 

mniunor 

;  MAMVOOV  TVPE; 

BISF  PORT 

:  PCRT  TYFB; 

REGISIBI 

:  RB5ISTB1  TYPE; 

FUG 

t  FUGjnPB; 

NOTJJSED 

:  FUG3IWEj 

end  record; 

for  BISF  use 

record 

INb'iWCTiCN 

at  0*WORD  range 

0..7; 

mcKcasa 

at  0*M0R)  range 

8..  9; 

BISF__PCRr 

at  O^VQBD  range 

10.. 11; 

RBSISTSl 

at  0*MCED  range 

12..  15; 

FUG 

at  l^MQRD  range 

0..15; 

MOTJJSET 

at  2*MQR}  range 

0..15; 

end  record; 


ei^  MAOUNBJXDB; 

A  BIST  instruction  can  now  inserted  into  the  Ada  code  by  including  the 
MACHINEJXDe  package  and  using  a  statement  similar  to  what's  given  below: 

BISF'ffilF,  1,  0,  0,  63,  0); 

Figure  3 


Trace  Buffer  Dmp 


Translation 


OaFB0006FFFF0001 

00FE0006FWF0002 

OOFB0006FFTF0003 

OOFB0006FTTF0008 

OOFE0006mF0009 

OOFB00020047FfTF 

000900020013FFTF 


Pxx3oe86  254  defines  Process  1 
Process  254  defines  Process  2 
Process  254  defines  Process  3 
Process  254  defines  Process  8 
Process  254  defines  Process  9 
Process  254  welts  on  Sonaphore  47 
Process  9  weits  on  Sauaphore  13 
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SOMMAAT 

This  paper  presents  our  experience  with  Ada-directed  software  development 
methodologies.  These  include  functional  programming  the  use  of  class 
instances  object-oriented  design,  and  Ada  as  a  program  design  language.  The 
paper  builds  upon  prior  experience  by  describing  an  automated  Ada  code 
generation  environment.  The  environment  addresses  the  enhancement  of 
existing  software  tools,  new  development  currently  underway,  and  compiler 
support  for  military  flight  computers  such  the  AN/AYK-li.  Finally,  military 
avionics  applications  of  such  an  environment  are  discussed.  Predicted 
improvements  in  the  areas  of  prototyping,  productivity,  reusability,  and 
maintainability  are  examined. 


1  .  ZMTROOOCTZOV  AMD  BACKGROUim 

The  United  States  Department  of  Defense  Ada  language  initiative  has  given  rise  to 
a  sense  of  mystique  within  the  weapon  system  community.  This  is  largely  a  side  effect 
that  results  from  confusing  Ada  linguistics  with  development  methodology.  As  the 
demand  for  mission  critical  avionics  software  continues  to  accelerate,  it  is  necessary 
that  our  industry  demystify  the  use  of  Ada  and  bring  effective  software  engineering 
techniques  to  bear. 

This  paper  suggests  the  principle  focus  of  avionic  software  development  should  be  on 
design,  and  that  production  of  Ada  (or  other)  source  code  should  be  automated. 

1 . 1  The  Ada  Imperative 

While  debate  continues  concerning  the  eventual  acceptance  of  the  Ada  programming 
language,  there  is  increasing  evidence  of  commitment  to  Ada  on  the  part  of  the  Department 
of  Defense.  Last  year,  Salomon  Brothers  published  a  thorough  review  [1]  of  Ada’s  status. 
Selected  details  of  the  report  are  summarized  below. 

In  1975,  the  High  Order  Language  Working  Group  performed  two  significant  actions. 
First,  they  officially  limited  the  languages  that  could  be  used  on  defense  contracts. 
Second,  they  established  a  set  of  requirements  for  a  new  language  that  could  be  used  for 
all  embedded  computer  systems.  The  final  language  design  was  selected  in  1979,  and  was 
called  Ada. 

In  1983,  Ada  was  recognized  as  a  standard  by  the  Department  of  Defense,  and  by  the 
American  National  Standards  Institute.  Ada  has  also  recently  been  accepted  as  an 
international  standard.  In  1983,  Ada  was  stipulated  for  use  in  all  new  mission-critical 
software  develo|xnent  programs. 

In  spite  of  this  stipulation,  many  waivers  were  requested  and  granted  in  the 
1983  to  1986  time  frame.  Largely  due  to  management  concerns  about  effects  on  schedule, 
cost,  and  reliability,  this  situation  resulted  in  only  limited  acceptance  of  Ada.  In 
1987,  two  new  Department  of  Defense  Directives  (3405.1  and  3405.2)  were  issued.  These 
directives  jointly  emphasized  the  requirement  to  use  Ada  on  defense  contracts,  and  made 
the  waiver  process  much  more  difficult. 

The  commitment  to  use  Ada  on  several  major,  current  system  acquisitions  (such  as 
Space  Defense  Initiative,  Advanced  Tactical  Fighter,  and  Federal  Aviation  Administration 
Advanced  Automation  System),  suggest  that  the  Ada  imperative  is  teal.  Therefore,  it  is 
in  the  best  interest  of  the  military  avionics  industry  to  consider  the  near-term  use  of 
Ada  as  likely,  and  to  evaluate  the  Implications  of  this  eventuality . 

1.2  Trends  Za  Avionics  Software  Criticality 

The  criticality  of  military  avionics  and  associated  software  is  increasing 
dramatically.  This  is  but  one  of  the  conclusions  supported  by  the  "Military  Avionics  in 
the  1990*s"  seminar  series  offered  by  Technology  Training  Corporation.  Information 
relevant  to  this  conclusion  is  discussed  in  this  section. 

The  percentage  of  military  aircraft  acquisition  cost  attributable  to  avionics  has 
effectively  doubled  in  the  last  twenty  years.  This  increase  is  in  spite  of  improved 
hardware  performance  and  decreased  hardware  cost.  The  percentage  growth  in  cost  of 
avionics  is  the  result  of  a  marked  increase  in  the  amount  of  embedded  avionic  software. 
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The  Increase  in  avionic  software  during  this  period  has  been  as  much  as  a  full  order 
of  magnitude.  There  are  three  important  reasons  for  this  increase.  First/  there  has 
been  an  increase  in  the  overall  functionality  of  the  weapon  systems.  The  quantity  of 
software  required  to  perform  the  additional  functions  has  kept  pace.  Second/  there  has 
been  a  somewhat  surprising  shift  in  the  functional  partitioning  between  hardware  and 
software.  Software  has  grown  from  perhaps  ten  percent  of  the  total  functionality  to  as 
much  as  thirty-five  percent.  Thus*  even  in  the  absence  of  other  factors/  the  amount  of 
software  would  increase.  And  third#  the  growing  pilot  workload  is  now  at#  and  in  some 
cases  well  beyond#  the  point  of  saturation.  To  counter  this  requires  a  significant 
redefinition  of  the  Pilot-Vehicle  Interface#  with  a  corresponding  increase  in  the  volume 
of  software. 

The  increasing  amount  and  coi^lexlty  of  this  embedded  avionic  software  would 
constitute  a  development  challenge  even  if  the  required  reliability  were  constant. 
However#  this  is  not  the  case.  An  additional  factor  is  the  increasing  criticality  of 
modern  avionics.  There  has  been  a  transition  that  started  with  mission  importance 
(digital  displays#  route  planning#  stores  inventory)#  has  passed  through  mission 
criticality  (terrain  following#  weapon  control#  inertial  navigation)#  and  has  now 
progressed  to  flight  criticality  (unstable  flight,  fly-by-wire#  engine  control) .  As  the 
role  of  the  avionics  becomes  more  critical#  the  required  software  reliability  increases. 

As  evidenced  by  the  Advanced  Tactical  Fighter  program#  the  trend  in  avionics 
continues  toward  increasing  amounts  of  software  and  increasing  reliability  requirements. 
Unfortunately#  the  United  States  STARS  (Software  Technology  for  Adaptable  Reuseable 
Systems)  Foundation  estimates  a  programming  personnel  shortfall  on  the  order  of  four 
percent  per  year.  Highlights  of  an  approach  to  reconciling  these  issues#  while 
addressing  the  Ada  imperative#  are  presented  in  the  next  section. 

1 . 3  Automatic  Programming  in  Ada 

Estimates  of  the  length  of  time  required  to  adequately  train  an  "Ada  developer"  are 
on  the  order  of  six  to  twelve  months.  This  is  certainly  enough  to  suggest  that  Ada  might 
be  very  difficult  to  use.  In  point  of  fact#  however#  an  experienced  programmer  can  learn 
Ada  syntax  and  semantics  in  one  week#  and  be  generating  functional  code  in  two  weeks. 
Given  some  experience  with  more  modern  high-order  languages#  such  as  Pascal  or  MODULA-2# 
one  can  be  writing  Ada  code  of  reasonable  quality  within  one  month. 

There  is  an  apparent  contradiction  here.  The  reason  is  that#  unlike  most  of  its 
predecessors#  the  Ada  language  was  designed  to  provide  integrated  support  for  modern 
programming  practices.  In  addition#  the  Ada  initiative  emphasizes  state-of-the-art 
software  engineering.  The  training  estimates#  therefore#  actually  consist  of  two  parts: 
becoming  a  qualified  software  engineer#  and  learning  how  to  program  in  Ada.  How  then 
should  industry  approach  the  training  of  Ada  developers? 

The  business  community  provides  a  model  that  applies  to  this  situation.  Problem 
analysis  and  specification  have  been  separated  from  the  Implementation  process.  Fourth 
generation  languages  address  the  problem  domain#  while  application  generators  offer  an 
automated  approach  to  the  solution  space.  Training  emphasis  is  on  problem  analysis;  the 
use  of  non-procedural  languages  enhances  productivity;  and  the  reuseable  application 
generators  are  more  cost-effective  than  ro^mually  creating  problem-specific  code. 

Consideration  of  the  above  model#  in  the  context  of  Ada  and  military  avionics 
software#  suggests  the  following  approach: 

•  concentrate  on  software  engineering  training 

•  support  design  methodology  with  automated  tools 

•  incorporate  mechanisms  for  design  and  code  reuse 

«  automate  the  generation  of  Ada  source  code 

•  focus  on  military  avionics  and  processors 

Section  2  discusses  techniques  that  constitute  a  foundation  for  automatic  programming  in 
Ada. 

2  .  RILIVAHT  METHODOLOGICAL  EXPERIENCE 

Coi^puter  Technology  Associates#  Inc.  (CTA)  is  applying  modern  software  engineering 
methodology  to  the  process  of  Ada  code  development.  The  work  is  being  performed  through 
government  contracts#  the  Small  Business  Innovative  Research  program#  and  Independent 
Research  and  Development  tasks.  This  section  discusses  several  activities  that  are 
relevant  to  Ada  code  generation. 

2 . 1  Ada  As  a  Fregram  Design  Language 

Perhaps  one  of  the  earliest  popular  methodological  efforts  was  the  use  of  Ada  as  a 
program  design  language.  CTA#  like  many  other  organizations#  attempted  to  use  Ada  in 
this  way.  Early  efforts  within  the  industry  were  hampered  by  a  widespread  lack  of 
uniformity  in  approach.  Although  a  recent  standard  [2]  has  been  issued  that  provides  a 
set  of  recommended  capabilities#  it  does  not  address  the  actual  usage  of  the  design 
language . 


CTA's  experience  with  Ada  as  a  program  design  language  was  useful  for  intercoo^nent 
interface  specification  (via  the  Ada  package  mechanism),  data  structures  (via  Ada 
declarations),  and  control  representation  (via  logic  constructs  and  procedure 
invocation).  However,  there  were  two  important  areas  that  did  not  provide  any  benefits. 
The  first  was  the  effort  required  to  specify  a  design  in  the  rather  verbose  Ada  syntax; 
and  the  second  was  the  need  for  formal  design  methodologies. 

2 . 2  jeek-'Oriented  Oeaigm 

In  his  paper  on  object-'oriented  development,  Booch  (3]  has  suggested  that  classical, 
"structured*  develofxsent  methodologies  do  not  lend  themselves  well  to  Ada  language 
features.  This  is  due  to  a  function-centered  view  that  does  not  fully  utilize  such  Ada 
features  as  abstraction,  genericity,  and  encapsulation.  He  makes  a  case  for  a  data- 
centered  approach  that  extends  the  system  development  concepts  developed  by  Jac)cson  [4] . 

CTA  has  found  this  object-oriented  methodology  to  be  a  sound  one,  and  well  suited  to 
coding  in  Ada.  The  close  parallel  between  problem  domain  elements  and  objects  in  the 
solution  space  produces  a  design  that  is  correct  by  inspection.  This  is  at  odds  with  the 
usual  arguments  of  correctness  that  are  based  upon  the  mapping  from  structured  designs 
back  to  the  problem  domain. 

CTA  has  been  developing  software  tools  for  object-oriented  design  development 
efforts.  There  are  now  several  tools  that  support  a  ranqe  of  activities,  from 
requirements  specification  (using  both  data  and  tunctional  views)  through  design  (with 
object  diagrams,  editors,  and  validity  checks) .  Experience  on  several  small  Ada 
development  projects  has  demonstrated  the  effectiveness  of  both  the  approach  and  the  tool 
set. 

2 . 3  Automatic  Programming  Techniques 

There  are  two  areas  of  research  that  CTA  has  been  pursuing  with  respect  to  automatic 
programming.  The  first,  referred  to  as  Ada  prespecifications,  considers  automated  code 
production  concepts  such  as  Martin  (5)  describes  for  fourth-generation  languages.  The 
underlying  technique  is  a  generative  one,  in  which  a  tailored  language  is  applied  to  a 
restricted  problem  domain;  the  resulting  prespecification  is  used  to  automatically 
generate  source  code  that  can  be  con^lled  for  subsequent  execution.  CTA  is  using  the  Ada 
language  itself  [6),  to  avoid  the  proliferation  of  languages  that  would  otherwise  result 
from  an  application  that  spanned  multiple  problem  domains.  The  Ada  prespecification 
includes  declarative  structures  in  place  of  a  domain-specific  metalemguage,  and  a  library 
of  code  body  generators.  Con^ilation  and  execution  of  the  prespecification  results  in  an 
Ada  code  body  that  implements  the  specified  design.  A  code  expansion  ratio  of  17-to-l 
for  Ada  source  lines  from  prespecification  lines  has  been  observed. 

The  second  area,  referred  to  as  functional  programming,  is  derived  from  the  use  of 
DeMarco's  [7]  data  flow  diagrams  as  a  means  of  specification.  This  is  a  constructive 
technique,  where  a  set  of  primitive  functions  are  defined  from  which  the  diagram  can  be 
composed.  The  data  flows  that  connect  the  functions  constitute  function  parameters  and 
results.  Constraints  are  used  to  ensure  that  the  diagram  construction  is  valid.  The 
resulting  symbolic  representation  is  the  input  to  a  translation  process  that  allows 
direct  execution  (interpretively)  of  the  specification.  CTA  has  demonstrated  this 
technique  in  a  system  that  provided  for  graphic  construction  of  a  series  of  aloebralc 
computations.  '  ^ 

2.4  Classes  and  Inheritance 

While  Ada  was  not  specifically  designed  to  be  an  object-oriented  programming 
language,  it  does  have  features  that  support  the  general  approach.  There  are  some 
i^ortant  concepts,  however,  such  as  the  class  hierarchy  and  inheritance  capabilities  of 
e  Smalltallc  language  (8),  that  are  not  well  supported  by  Ada. 
Seidewltz  [9]  gives  examples  of  these  concepts,  and  shows  how  they  might  be  represented 
in  programs.  Unfortunately,  it  is  necessary  for  the  programmer  to  manually  elaborate 
the  design  with  applicable  Ada  constructs.  This  is  not  an  optimal  approach,  from  either 
the  development  or  maintenance  point  of  view, 

CTA  has  developed  an  alternate  mechanism  for  incorporating  classes  and  inheritance. 
Using  the  Ada  prespecification  method  discussed  above  in  section  2.3,  class  definitions, 
hierarchies,  and  inheritance  information  are  provided  in  tha  prespecification 
declarations  in  a  form  designated  as  a  "phylum".  An  invocation  is  made  upon  the  phylum 
Ada  code  generation  function,  with  the  associated  code  body  library.  The  result  (after 
compilation  and  execution  of  the  prespecification)  is  a  compliment  of  Ada  packages, 
interfaces,  and  procedures  that  provide  the  necessary  structure  for  the  design 
in^lementation . 
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2 . 5  Concepts 

CTA  has  evaluated  concepts  for  the  reuse  of  Ada  development  products.  Perhaps  the 
most  obvious  approach  is  reuse  of  the  code  itself.  For  exan^le^  Booch  [10]  has  defined  a 
taxonomy  for  data  structures  and  manipulation/  and  has  developed  a  collection  of  well* 
documented/  validated  Ada  software  coa^onents.  This  concept  does  not  address  tailored 
implementation  that  results  from  the  target  environment.  Neither  does  this  concept  lend 
itself  well  to  application-specific  problems/  where  requirements  differences  may 
necessitate  alternate  designs.  The  notion  of  a  taxonomy  is  an  important  aspect  of  this 
approach/  as  it  provides  a  method  to  categorize  and  organize  the  code  bodies.  While 
classification  is  not  discussed  any  further,  it  is  central  to  all  reuse  concepts. 

A  second  approach  is  the  reuse  of  design  components.  These  "objects*  encapsulate 
data  structures  and  a  set  of  operations  on  the  data.  This  allows  reuse  at  a  higher  level 
of  abstraction,  in  a  manner  that  is  closer  to  the  problem  domain.  Tailoring  for  the 
target  environment  is  accomplished  during  implementation.  If  an  automatic  code 
generation  mechanism  is  used,  object  reuse  can  be  an  effective  labor  reduction  technique. 

A  still  higher  level  of  abstraction  is  available  through  the  use  of  classes,  as 
discussed  in  section  2.4,  and  the  inheritance  mechanism.  This  "specification  reuse" 
concept  is  inherent  in  the  inheritance  process,  with  application-specific  adaptation 
through  overriding  selected  superclass  capabilities,  or  by  the  addition  of  new 
capabilities  to  the  subclass.  Bailin  [11]  presents  CTA  progress  towards  a  software  reuse 
environment  that  is  based  upon  the  class  hierarchy  approach. 

3.  AH  AOTOKATID  ADA  CODS  GHHIItATlOH  BHVXROHNBHT 

This  section  proposes  environmental  concepts  that  support  the  automated  generation 
of  Ada  source  code.  The  concepts  are  discussed  presented  within  the  context  of  a 
classical  system  development  life  cycle,  as  listed  below. 

*  system  requirements  specification 

*  system  architecture  definition 

*  element  requirements  analysis 

*  element  design  synthesis 

*  element  implementation 

*  integration,  test,  and  evaluation 

*  operation  and  maintenance 

Note,  that  while  an  architectural  element  consists  of  hardware  and/or  software,  this 
paper  addresses  only  the  software  portion.  Issues  concerning  "software  first",  "software 
in  hardware"/  and  "software/hardware  partitioning"  are  not  discussed. 

The  focus  of  this  section  is  on  software:  specification  of  requirements  and  design, 
code  generation,  and  support  for  target  avionics  processors.  Application  of  object- 
oriented  principles  to  system  requirements  and  architecture  appears  to  be  premature  at 
the  present  time,  although  capability -based  computer  systems  are  likely  to  change  this 
situation. 

3 . 1  Software  Requirements  and  Design  Specification 

Historically,  the  processes  of  requirements  analysis  and  design  synthesis  have  been 
differentiated  by  the  characteristics  of  their  respective  engineering  activities.  It 
could  be  argued  that  this  is  an  artificial  distinction,  resulting  from  the  problem  domain 
and  solution  space  dichotomy  that  section  2.2  discussed.  CTA  has  found  that  object- 
oriented  development  blurs  this  distinction.  The  analysis  process  defines  hierarchies  of 
objects,  each  with  data  and  function  content.  The  lowest  level  of  the  object 
"decomposition"  becomes  pure  function.  Synthesis,  then,  is  the  process  of  adding  design 
detail,  rather  than  one  of  recasting  the  problem  domain  into  a  solvtion  space. 

The  foundation  of  the  development  environment,  therefore,  is  an  object-oriented 
development  approach.  This  includes  the  class  and  inheritance  concepts  of  section  2.4, 
where  the  class  phylum  consists  of  problem  domain  objects.  This  does  not  suggest  that 
there  is  no  role  for  traditional  structured  analysis  techniques.  CTA's  recognition  of 
this  continuing  role  has  been  to  develop  a  tool  by  which,  given  an  both  "annotated"  data 
flow  diagram  and  an  entity  relationship  diagram,  a  preliminary  object  hierarchy  is 
generated.  The  object-oriented  design  is  then  completed  through  the  use  of  graphic 
editors.  While  additional  development  would  be  required  to  accommodate  other  possible 
forms  of  inputs,  the  framework  has  already  been  developed  and  is  in  use  at  CTA. 
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The  Issue  of  foraal  specification  is  more  coaplicated.  The  Department  of  Defense 
stipulates  a  the  development  life  cycle,  standards  to  be  employed,  and  documents  to  be 
produced.  These  are  not  well  suited  to  object-oriented  development  and  resulting 
specifications.  A  number  of  vendors  are  beginning  to  address  the  semiautomatic 
generation  of  standard  specifications  from  Internal  requirements  and  design 
representations.  A  partial  list  of  such  products  and  vendors  is  given  below. 

•  STATEMATE,  by  i-Logix 

•  CABDtools,  by  Ready  Systems 

•  TekCASE,  by  Tektronix 

•  TAGS  CASE2,  by  Teledyne  Brown 

•  superCASE,  by  Advanced  Technology 

Typically,  the  tools  are  based  upon  structured  analysis,  rather  than  object-oriented 
development.  CTA  has  not  yet  assessed  the  practicality  of  using  their  internal  data 
representations  as  Inputs  to  the  object  generator.  A  recent  software  development 
standard  [12]  does  suggest  a  more  liberal  approach  to  the  life  cycle,  that  could 
encoiiq>ass  object-oriented  development.  The  required  specifications  do  not  offer  such 
latitude,  however.  The  conclusion,  therefore,  is  that  evolution  of  the  mandated  process 
and  products  must  continue  in  order  for  object-oriented  software  development  to  be 
accommodated. 

3 . 2  Automated  Source  Code  Ganeratlom 

For  the  purpose  of  this  paper,  automated  generation  refers  to  any  mechanism  from 
which  source  code  results  other  than  manual  entry.  For  example,  perhaps  the  most  obvious 
’automated*  technique  is  reuse  of  existing  code.  While  this  is  actually  a  constructive 
approach,  rather  than  a  generative  one,  it  does  not  require  manual  code  development. 
Automated  support  is  provided  by  a  reuse  environment  that  facilitates  identifying 
appropriate  code  bodies  as  a  consequence  of  the  object-oriented  requirements  and  design 
elaboration  process.  To  increase  the  probability  that  the  appropriate  code  bodies  exist 
and  can  be  identified,  it  is  important  that  they  be  originally  developed  through  the 
object-oriented  facilities  of  the  reuse  environment. 

A  second  automated  approach  la  that  of  Ada  prespecification.  This  is  a  generative 
technique,  that  creates  Ada  code  from  the  problem  domain  metalanguage.  In  general,  any 
system  object  could  be  a  candidate  for  having  its  own  metalanguage.  The  functional 
aspects  of  the  object  would  be  expressed  in  a  prespecification,  with  subsequent 
generation  of  the  Ada  code.  CTA  is  currently  in  the  process  of  incorporating  this 
capability  into  the  existing  object-oriented  development  tool  set. 

Metalanguage  prespecifications  will  not  be  applicable  to  all  types  of  objects.  This 
is  especially  true  for  computationally  Intensive  numerical  applications.  There  are  other 
techniques  to  support  code  automation  in  these  cases.  One  is  the  use  of  Ada  as  a  program 
design  language.  Algorithmic  details  are  expressed  in  Ada,  with  the  type  and  variable 
bindings  established  through  an  automated  generation  step.  CTA  is  also  incorporating 
functional  programming  as  a  design  elaboration  technique.  Specifically,  a  set  of 
functional  primitives  (code  fragments)  can  be  associated  with  data  elements  through  the 
data  flow  diagram.  An  automated  construction  step  will  bind  the  Ada  code  and  data  for 
inclusion  in  the  final  packages. 

In  all  of  the  above  techniques  there  will  remain  a  need  for  manual  editing, 
tailoring,  and  selective  optimization.  This  can  be  provided  through  syntax-directed 
editors,  such  as  currently  available  in  CTA's  object-oriented  development  tool  set.  Note 
that  manual  modification  introduces  a  new  variant  of  a  code  body.  While  its  position 
within  the  object  phylum  is  unchanged,  it  becomes  available  only  through  construction; 
generation  could  no  longer  be  used  to  produce  the  variant  automatically. 

3 . 3  Target  Processor  Support 

The  Ada  language  provides  a  number  of  mechanisms  to  match  a  program  to  its  target 
processor.  These  include  representation  specifications,  pragmas,  and  implementation 
dependent  features.  The  use  of  these  mechanisms  is  a  manual,  labor-intensive  activity 
for  which  automated  support  would  be  very  beneficial.  Further,  tne  inclusion  of  such 
information  affects  the  reusability  of  the  software.  One  approach  would  be  to  include 
the  target  processor  specifics  as  library  variants,  thus  allowing  their  inclusion  in  a 
transparent  manner.  This  approach  has  the  disadvantage  of  many  versions  of  library 
modules  lielng  required.  There  is  evidence  in  the  industry  that  an  alternative  approach 
is  gaining  emphasis,  that  of  rule-based  tailoring.  The  benefit  of  this  approach  would  be 
the  retention  of  only  general  forms  of  the  software,  with  the  target  processor  specifics 
introduced  prior  to  compilation.  This  artificial  intelligence  technology  appears  to  be 
critical  for  the  effective  reuse  of  software  across  processors. 
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A  major  issue  is  the  availability  of  validated  compilers  for  avionics  target 
processors.  Under  the  auspices  of  United  States  Armed  Forces  programs  (i.e.,  the  Ada 
Integrated  Environment  and  the  Ada  Language  System) ,  compilers  have  been  developed  for 
the  following  processors: 

•  1750A  (Air  Force) 

•  NC68000,  NS32000,  80X86  family 

•  AN/UYK-43,  AN/UYK-44,  AN/AYK-14  (Navy) 

While  coQ^ilers  are  continually  being  developed,  greater  support  for  typical  embedded 
avionic  processors  is  required.  Integration  of  environments  for  object-oriented 
development,  code  generation,  target-specific  tailoring,  and  compilation  will  be 
difficult  in  the  near-term.  However,  as  the  environments  themselves  Income  products  of 
object-oriented  Ada  development,  ease  of  integration  will  be  a  natural  consequence. 

One  final  support  issue  is  the  target  processor  execution  environment.  There  are 
concerns  about  the  real-time  capability  of  the  executive  programs  and  run-time  services. 
There  are  also  concerns  about  the  non-homogeneous  interfaces  provided  by  these 
components.  While  there  is  only  limited  real-tiiM  Ada  execution  experience  at  this  time, 
there  is  reason  to  believe  that  several  factors  support  its  practicality:  increasing 
speed  of  hardware;  improving  efficiency  of  compiled  code;  and  application  of  proven 
design  approaches.  In  particular,  there  is  nothing  inherent  in  Ada  to  preclude  the  use 
of  established  deterministic,  synchronous  design  techniques  that  are  typically  employed 
in  real-time  software.  The  inconsistent  execution  environment  services  and  interfaces 
pose  a  more  difficult  problem.  However,  the  essence  of  the  solution  lies  in  the  target 
processor  tailoring  approaches  discussed  above,  in  addition,  the  various  Ada  environment 
communities  are  aware  of  this  issue,  and  are  wor)cing  toward  standards  that  will  eliminate 
the  problem  in  the  future. 

3.4  A  ■ear-Term  Prototype 

While  work  remains  to  be  done,  the  preceding  sections  show  that  substantial  progress 
has  been  made.  By  the  end  of  1988,  CTA  expects  to  have  an  operational  version  of  the 
object-oriented  development  system,  including  the  following  capabilities. 

•  object-oriented  analysis  and  synthesis 

•  structured  analysis  requirements  interface 

•  design  elaboration  by  prespecifications 

•  design  elaboration  by  functional  programming 

«  automated  Ada  code  generation 

•  phylum-based  reuse  environment 

The  work  currently  under  way  concerns  integration  of  the  Ada  code  generation  capabilities 
developed  by  CTA  under  separate  research  projects. 

To  complete  the  prototype  environment,  CTA  is  in  the  process  of  selecting  a  suitable 
avionic  software  development  project,  for  which  commercial  target  processor  support  is 
available.  In  this  way,  an  object-oriented  Ada  development  effort  could  be  pursued 
during  1989  with  no  additional  environment  enhancements  required.  CTA  is  also  involved 
in  the  evaluation  of  a  number  of  vendor  products  that  could  be  integrated  into  the 
environment  as  part  of  the  prototype  effort. 

4.  NILITART  AVIOMICS  APPLICATIONS 

This  section  discusses  benefits  that  would  result  from  the  application  of  an 
automated  code  generation  environment,  such  as  described  in  section  3,  to  military 
avionics  programs.  Avionic  software,  while  conceptually  similar  to  other  types  of 
software,  has  typically  suffered  from  the  following  shortcomings: 

•  ineffective  use  of  related  heritage 

•  labor-intensive  code  development 

•  long  concept  to  validation  interval 

•  high  maintenance  activity  costs 

These  topics  are  addressed  below,  by  first  describing  the  nature  of  the  avionics  software 
problem,  followed  by  examining  benefits  of  the  automated  environment. 

4 . 1  If feetiwe  Heritage  lease 

There  are  certainly  differences  among  airframes,  missions,  and  armaments.  The  focus 
seems  to  be  on  these  differences,  rather  than  on  the  many  similarities.  One  possible 
explanation  is  the  acquisition  process  itself,  whereby  the  platforms,  and  even  models 
within  a  given  platform  series  are  manufactured  by  different  prime  contractors  and 
subcontractors.  This  leads  to  a  highly  coBg>etitive  arena,  with  diverse  developers,  in 
which  there  is  a  lack  of  developmental  history  and  sharing. 

A  less  obvious  explanation,  perhaps,  is  the  consequence  of  functional  versus  object- 
oriented  development.  The  functional  approach  typically  evolves  along  the  lines  of 
related  software  process  aggregation;  this  tends  to  involve  a  large  number  of  interfaces 
between  software  functions  and  hardware  devices.  Changes  to  the  avionic  hardware  suite, 
therefore,  effect  much  of  the  software  design. 
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The  proposed  development  environment  would  provide  benefits  with  respect  to  both  of 
the  above  issues.  Object  reuse  and  the  phylum  object  hierarchy  provide  a  mechanism  for 
starting  with  the  general  and  tailoring  to  the  specific.  Coupled  with  the  inheritance 
concept,  this  would  allow  reuse  of  any  existing  relevant  objects,  with  addition  of  new 
and  specific  capabilities.  Ada  language  features,  with  deferred  target-processor 
tailoring,  provide  an  opportunity  for  increased  code  reuse.  And  the  object-oriented 
approach  would  reduce  the  impact  of  subsystem  changes,  by  localizing  their  effects  within 
the  related  objects.  A  final  improvement  would  be  realized  if  the  Department  of  Defense 
were  to  incorporate  all  avionic  program  developments  into  a  master  phylum  object  data 
base,  and  provide  it  to  every  contractor.  In  this  way,  heritage  reuse  across  all  avionic 
development  efforts  could  be  achieved. 

4.2  Increased  Productivity 

Code  production  is  a  labor-intensive  process.  In  the  case  of  avionics  software, 
this  is  often  exacerbated  by  the  use  of  low-level  languages.  Although  the  use  of  high- 
level  languages  does  improve  this  somewhat,  the  process  itself  is  still  time  consuming. 
Xn  most  projects  code  production  will  account  for  about  ten  percent  of  the  total  labor. 

The  immediate  benefit  of  the  proposed  environment  is  the  automated  production  of 
code.  While  this  is  especially  true  of  generative  techniques,  late  target  processor 
binding  allows  for  increased  use  of  existing  code  by  constructive  techniques  as  well. 
Perhaps  the  single  most  common  objection  to  automated  code  production  is  efficiency;  of 
course,  this  is  also  the  most  common  objection  to  the  use  of  high  level  languages.  The 
response  in  the  same  to  both  objections:  first,  hardware  capacity  increases  are  making 
this  a  moot  point;  and  second,  it  has  been  shown  that  selected  optimization  after 
implementation  is  the  most  effective  and  cost-effective  way  to  achieve  the  required 
performance. 

4.3  Rapid  Concept  Validation 

Avionics  software  development  typically  exhibits  long  time  intervals  between  concept 
formulation  and  validation.  In  part,  this  is  a  consequence  of  the  lack  of  heritage  and 
manual  code  production  issues  discussed  above.  In  addition,  budget  and  schedule  rarely 
allow  for  extensive  proof-of-concept  phases  that  employ  language  and  execution 
environments  different  from  the  target  processor. 

Inherent  in  the  proposed  environment  is  the  capability  to  rapidly  develop  prototype 
systems.  Genericity,  abstraction,  and  reuse  facilitate  the  construction  of  operational 
software  from  the  data  base  of  previously  defined  objects.  The  Ada  code  would  be 
executed  initially  on  the  host,  with  target  processor  binding  at  a  later  time.  In  fact, 
automated  target-specific  tailoring  would  allow  testing  on  similar  hardware  prior  to 
availability  of  the  actual  avionic  equipment.  Early  focus  on  similar  features,  tailoring 
of  unique  aspects,  and  late  target  processor  binding  support  rapid  concept  implementation 
and  validation. 

4 . 4  inhanced  Nalataloablllty 

Entropy  has  a  tendency  to  degrade  the  maintainability  of  all  software.  Military 
software  also  suffers  from  being  removed  in  distance  from  the  maintenance  organization. 
Unfortunately,  this  seems  to  accelerate  the  deterioration  of  both  the  software  and  the 
associated  development  documentation. 

The  proposed  environment  does  not  offer  any  maintenance  features  that  are  unique  to 
avionics  software.  However,  any  improvement  in  the  maintenance  process  will  result  in 
significant  cost  savings.  The  object-oriented  development  process  does  offer  several 
benefits.  One  of  these  is  the  ability  to  work  at  higher  levels  of  abstractions.  This 
reduces  the  overall  scope  of  the  modification  process.  Since  code  is  an  end-product 
derived  from  the  overall  process,  not  an  independent  development  step,  all  changes  start 
with  the  specification,  and  propagate  through  to  the  code.  The  result  is  that  the 
software  maintenance  process  also  maintains  the  integrity  of  the  object  hierarchy.  The 
ultimate  benefit  is  consistent  and  complete  specifications,  with  highly  leveraged  labor, 
in  contrast  with  maintenance  efforts  that  focus  on  code  level  modifications. 

5.  SDMNART  AMD  COMCDOSIONS 

This  paper  suggests  that,  as  a  consequence  of  the  coming  Ada  imperative  and  the 
increasing  quantity  and  complexity  of  avionic  software,  improved  development 
methodologies  are  needed.  CTA  has  addressed  such  innovations,  and  has  experience  that 
demonstrates  their  effectiveness.  An  approach  to  an  automated  Ada  development 
environment  has  been  proposed,  of  which  many  elements  exist  today  and  others  are  being 
added. 

A  pilot  avionic  software  development  project  is  feasible  within  the  next  year,  using 
the  proposed  environment.  The  paper  has  discussed  application  of  the  methodological 
principles  to  Ada  code  generation.  While  Ada  supports  these  object-oriented  ideas,  and 
is  intended  for  widespread  use  within  the  defense  industry,  it  should  be  noted  that  the 
automatic  prograinaing  mechanisms  are  not  unique  to  Ada,  and  could  be  used  to  target  other 
languages . 
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DISCUSSION 


M.Miieiiier,  Fr 

According  to  your  presentation,  it  seems  that  a  whole  environment  covering  requirements  and  design  specification  and 
coding  is  not  yet  available.  Would  you  comment  on  the  status  of  your  project  and  the  plaimed  development? 

Author’s  Reply 

For  both  automatic  programming  techniques,  the  “toot”  is  essentially  an  environment  for  employing  the  software 
components  developed  by  a  domain  expert. 

In  the  case  of  Ada  prespecificalions,  the  domain  expert  specifies  a  domain-specific  metalanguage  (i.e.,  for  graphics,  data 
management,  device  class  control,  etc.).  For  each  metalanguage  construct  he  then  develops  an  Ada  body  generator 
procedure  (in  Ada).  The  “tool”  provides  the  mechanisms  for  users  to  develop  their  metalanguage  specifications  and  to 
invoke  the  appropriate  code  generation  procedures. 

In  the  case  of  functional  programming,  the  domain  expert  would  develop  a  set  of  Ada  code  body  functional  primatives. 
The  “tool”  provides  a  graphic  interface  to  construct  data  flow  diagrams  from  the  functional  primatives,  enforces  certain 
conventions  to  eliminate  possible  ambiguities  and  constructs  the  code  body  procedure  invocations  necessary  to 
“implement”  the  specified  diagram. 


WJVIaiHel,Ge 

Can  you  add  some  comments  about  the  tools  developed  and  used  for  the  design  specifications  and  the  code  generation 
from  a  library  of  Ada  code? 

Author’s  Reply 

At  the  present  time,  we  have  a  core  of  Object-Oriented  Development  (OOD)  tools.  Ada  prespecifications  (including 
the  Phylum  Mechanism)  have  been  demonstrated  and  are  being  incorporated  into  the  OOD  toolset  this  year.  A 
rudimentary  demonstration  of  the  functional  programming  concept  has  been  accomplished;  this  year  we  are  extending 
(generalizing)  the  concept  and  incorporating  it  into  the  OOD  toolset  as  well.  When  complete,  this  will  provide  an 
integrated  toolset  capable  of  supporting  all  activities  up  through  execution  of  general  (host)  Ada  programs. 

The  target  processors  specific  tailoring,  cross  compilation  and  run  time  binding  will  be  provided  by  a  commercial 
product  for  a  selected  application.  We  have  no  plans  to  attack  the  expert  system  approach  to  target  processor  tailoring 
at  this  time,  although  we  are  following  some  on-going  work  by  other  groups. 

The  reuse  environment  is  under  development  as  part  of  a  NASA  Goddard  Contract.  When  complete,  it  will  also  be 
incorporated  into  our  OOD  toolset.  The  toolset  currently  tuns  on  a  Sun  workstation.  We  are  in  the  process  of 
transporting  it  to  a  DEC  Vax  station. 
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SUMMARY 


The  complexity  and  the  fault  tolerance  requlremente  of  flight  critical  avateaa  are  rapldlv  increeelng. 

Nev  technlquee  and  methoda  nuat  be  developed  and  «uet  be  Integrated  with  exlatlng  ipethoda  ao  that  the 
rlgoroua  technical  obiectlvea  of  the  verification  and  validation  proeeaa  of  such  avatena  can  be  net  at 
reaaonable  coat.  Thla  paper  exanlnea  aone  of  the  advanced  requlrenenta  of  theae  avatena  In  the  crltlca'' 
areaa  for  ayaten  architecture  and  aoftware  dealgn.  Some  pronlalng  technlquee  are  deacrlbed  which  can 
effectively  aupport  architectural  dealgn  end  analvala  and  aoftware  development  and  verification. 

1.0  IWTRODUCTIOW 

The  use  of  digital  technologv  In  flight  critical  applications  haa  permitted  subatantlal  imprnvenenta  In 
vehicle  and  mlaalon  performance  because  of  the  flexibility  cf  design  and  Imnlenentatlon  It  provldaa.  The 
requlrementa  for  ever  Increasing  functional  performance  and  reduced  pilot  workload  have  resulted  In 
complex  flight  control  system  architectures  and  coMxnicatlona  achemea  and  eorrespondlnglv  complex 
aoftware.  Such  ayatema  often  are  safety  critical  during  some  flight  regimes  and,  In  some  cases,  during 
the  entire  flight.  Redundancv  and  advanced  fault  tolerance  techniques  are  needed  to  meet  the  aafetv 
requlrementa  of  those  aystems.  The  resultant  complexity  of  avatem  architecture  and  embedded  aoftware  la 
aueh  that  the  current  verification  and  validation  techniques  and  methods  may  not  be  technically  adequate 
and  coat  effective.  In  this  paper  some  critical  technology  needs  are  described  for  supporting  the 
development  and  verification  process  of  the  highly  Integrated  flight  critical  avatems  of  the  next  gen¬ 
eration  of  aircraft.  Two  methods  are  also  described,  which  if  appropriately  Integrated  with  existing 
technology,  can  satisfy,  at  least  In  part,  those  needs. 

2.0  SYSTEM  RFOUIREKEWTS 

The  functional  raqulranents  and  the  architectures  of  automatic  flight  avstema  are  continuously  evolving 
(D*  MS  Fig.  1.  Limited  authority,  analog,  ftabiticv  augmentation  syatema  (5AS)  were  developed  during 
the  lS50*a  and.  ware  followed  bv  tha  flight  critical  analog  fllght-by-wlre  fFBWI  svatema  during  the 
IV70*a.  The  development  of  flight  critical  digital  FEW  fPn>-F8W)  systems  started  in  the  esrlv  IVRO’s, 
and  It  la  still  evolving.  Flight  critical  FBW,  in  thla  context,  means  that  loss  of  thnt  avatem  results 
In  catastrophic  consequences  for  the  aircraft  and  possibly  the  pilot.  The  trend  la  clesrlv  eatahilshed 
towards  aystama  which  arc  Increasingly  complex  and  critical.  The  evolution  and  ensuing  complexltv  of 
flight  control  avstema  have  been  accelerated  by  the  need  to  tncresae  aircraft  dynamic  and  operational 
performance.  Specific  contributors  to  thla  trend  ere: 

a)  The  development  of  multimode  control  lavs  which  permit  the  tailoring  of  the  vehicle  dvnamfca  and 
handling  qualities  to  specific  mlaalon  phases,  such  as,  takeoff  snd  landing,  cruise,  atr-ro-air  combat, 
and  air-to-aurface  attack.  Utilisation  of  task  tailored  control  laws  allows  the  enhancement  of  flvfng 
qualltlaa  In  particular  mission  segments  without  compromise  to  other  mission  segments. 

b)  The  integration  of  flight  control  with  other  aircraft  and  mission  functions  which  Improve 
vehicle  performance  and  Corel  aircraft  ayatem  efficiency  and  decreases  pilot  workload.  Examples  of  such 
aystama  are  tha  Intagratlon  of  flight  and  propulsion  control,  fire  control,  and  inertial  navigation 
ayatesa.  Control  and  avlonlea  functions  are  being  coupled  to  satisfy  advanced  mlaalon  requirements,  atich 
as  terrain  folloving/tarrcln  avoidance  (TF/TA)  miaaiona.  Theae  applications  require  senaorv  functions 
such  as  terrain  data,  radar  altitude,  terget  acquisition  and  tracking,  and  Inertial  reference  ayatem 
data,  in  addition  to  flight  control  functions.  The  Integration  effort  may  be  further  expanded  to  Include 
control  of  utility  functions  such  as  electrical  and  hydraulic  power,  environmental  control  and  fuel 
management.  Such  aystems  ara  referred  to  at  vehicle  management  ayatema  CVHS). 

c)  The  need  to  meet  stringent  safety-of-fllght  requlremerta  and  the  corresponding  reliability, 
availability  and  fault  tolarance  requirements.  In  some  caaea,  the  boundaries  of  flight  critical  control 
functions  ara  grovlng  beyond  the  classical  control  aystems  applications  discussed  above,  as  In  the  case 
of  highly  Integrated  military  applications.  As  an  example,  mlastnns  such  as  TF/TA  snd  nsp^f-the-earth 
(NOS)  mast  be  considered  not  only  mlaalon  critical  but  flight  critical  since  loss  or  malfunction  of  these 
aystama  may  result  In  cataatrophlc  consequences. 

The  flight  safety,  reliability  requlrementa  of  critical  flight  control  ayatema  la  not  to  exceed  10-^ 
cataatrophlc  fallurea/bour  (F/H)  in  the  case  of  military  aircraft,  and  10-^  catastrophic  F/U,  In  the  esse 
of  coeMrlcal  aircraft.  The  failure  rates  of  tvplcel  flight  control  components  exceed  those  requirements 


by  aaversl  order  of  magnitude.  Fig.  2.  It  la  therefore,  necessary  to  design  redundant  conf Iguratiors  so 
that  flight  safety  fsllurca  can  only  occur  sa  a  result  of  multiple  fstlures. 

The  qusntleatlye  requirements  for  flight  control  systsm  flight  saferv  are  given  In  MIT.-F-R7242  ^2)  for  UR 
military  ayatema.  The  guidelines  for  the  certification  of  commercial  aircraft  ere  deacrlbed  In  the  Code 
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of  Federal  Fegulatlon  (CFR)(3).  The  CFR  atatea  that  ayatep  failures  which  prevent  continued  safe  flight 
and  landing  of  the  aircraft  mat  he  extre«ely  litprohable«  'Hie  CFRa  do  not  define  a  naxiaun  arceptable 
frequency  of  auch  fallurea.  The  norvally  excepted  Interpretation  of  extremely  Improbable  la,  however*  a 
frequency  of  occurrence  not  higher  than  10  F/li,  aa  prevloualv  stated.  5?lmnar  guide! Inea  also  exist 
for  commercial  aircraft  certification  in  all  NATO  countries. 

It  must  be  noted  that  the  failure  rate  requirements  refer  to  the  hardware /software  combination.  During 
the  syatea  development  process*  however*  the  assumption  la  often  made  that  the  software  does  not  contrib¬ 
ute  to  the  system  failure  rate.  The  software  la  assumed  to  be  error  free  through  a  combination  of 
stringent  development  and  verification  techniques  and  other  design  considerations  ae  described  later  In 
this  paper.  This  approach  la  at  least  in  part  justified  by  the  fact  that  the  current  software  technologv 
does  not  support  s-priorl  quantitative  asaeasment  of  the  probability  of  residual  errors.  The  final 
outcome  la  that*  In  moat  cases*  the  avstem  level  reliability  la  met  bv  providing  the  appropriate  level  nf 
hardware  redundancy  only.  In  some  cases*  as  further  discussed  later  in  this  paper*  dissimilar  software 
Is  also  used  to  provide  some  level  of  software  redundancy.  The  purpose  is*  however*  to  achieve  software 
fault  tolerance  rather  than  a  quantifiable  and  demonstrable  improvemenr  of  software  rellabllitv. 

In  the  following  sections  of  the  paper*  the  characteristics  of  the  software  required  for  such  systems  and 
the  software  development  and  verification  process  will  be  described. 

3.0  SOFTWARE  CHABACTERTSTICS 


To  determine  the  required  characteristics  of  flight  software.  It  Is  necessary  to  consider  the  control 
system  characteristics  and  the  Implications  on  mechanisation  of  the  software  (4> .  Table  1  summarises 
these  characteristics  and  resultant  software  Impllcatlona. 

The  organisation  of  the  embedded  flight  software  la  bv  design  very  simple  given  the  critical  and  complex 
nature  of  the  application.  It  imptiea  the  repetitive  execution  of  application  tasks*  which  once  initi¬ 
ated*  are  non-lnterruptlble  and  must  execute  to  completion  within  a  predefined  period  of  time.  To  gain  a 
better  tinderatandlng  of  the  computational  requirements  of  such  systems*  the  software  is  partitioned 
according  to  the  major  functions  to  be  performed.  They  are: 

a)  Application.  The  algorithm  included  in  this  function  are  those  required  for  sensor  processing 
and  filtering*  control  and  navigation  algorithms*  and  computation  of  control  commnnda. 

b)  Logic.  Modules  In  this  category  perform  the  computation  required  for  switching  control  and 
flight  mode,  and  engaglng/dlsengaglng  logic.  They  use  almost  exclusively  boolean  statements. 

c)  Testing  and  Voting.  These  modules  perform  real  tine  test  on  processors,  memorv,  sensors  and 
actuators.  They  manage  and  control  the  overall  svatem  configuration  aa  a  ^unction  of  detected  failures. 
Bullt-ln-test  (BIT)  la  Included  In  this  category. 

d)  Input/Output .  Theae  modules  perform  data  handling  and  formatting*  data  transmission  and  dis¬ 
play.  Peripherals  drivers  are  Included  In  this  category. 

e)  Executives,  These  modules  perform  the  task  of  Inltlallratlon,  power-up  procedures*  synchro¬ 
nisation,  scheduling  and  timing. 

The  typical,  memory  requirements  of  each  software  function,  as  a  percentage  of  the  total,  ara  shown  In 
Table  2,  The  data  shown  In  the  table  represent  an  average  <  f  several  svstems  for  military  and  coTPrerclal 
eircratt.  Clearly,  differences  do  exist  from  case  to  case.  As  an  example*  In  the  case  of  a  svsten  which 
relics  significantly  on  self  test  for  the  purpose  of  failure  detection  and  isolation*  testing  does  take  a 
larger  percentage  of  the  total  memory  than  that  shown  In  the  table.  Complex,  highly  redundant*  dis¬ 
tributed  configurations*  have  relatively  high  logic,  testing  and  executives  content.  Simplex  config¬ 
urations*  with  limited  integration  of  functions,  tend  to  bnve  a  relatively  high  application  content. 

Equally  Important  for  understanding  the  software  of  critical  systems  Is  to  analvre  the  nature  of  the 
software  errors  which  are  detected  during  software  and  system  development.  A  common  characteristic  of 
all  prograna  which  were  analvred  Is  that  the  malorlty  of  softwar®  errors  are  generated  during  the  early 
phases  of  the  development  process  including  definition  of  requirements*  and  the  development  of  specifica¬ 
tions  and  design.  Five  general  error  categories  have  been  Identified  with  the  frequency  of  occurrence  of 
each  category  In  Table  3. 

It  Is  Important  to  notice  that  the  table  does  not  Include  the  occurrence  o'  trivial  coding  errora,  which 
are  easily  detected  during  software  coding  and  debugging  and  even  during  module  testing.  The  table 
Includes  only  those  errors  which  were  detected  while  the  software  was  already  In  conflg:urat1on  control, 
and  therefore  had  already  been  extensively  tested  at  the  module  level  and  at  the  level  of  software 
Integration.  Those  errors  were  detected  during  the  software /hardware  Integration  teat*  Iron  bird  test, 
and  flight  test.  Most  errors*  as  previously  stated,  are  a  result  of  Incomplete  or  inconalstent  require¬ 
ments*  Incorrect  specifications  and/or  poor  or  wrong  design  decision.  The  table  shows  that  errors 
associated  with  logic,  interfaces  and  data  handling*  including  testing  and  voting  are  the  biggest  con¬ 
tributors.  There  are  some  reasons  for  this  to  occur.  Those  areas  are  In  fact  rather  new,  relative  to 
the  application  functions.  The  necessary  tools  are  not  well  developed  and  the  understanding  of  complex 
architectures  (and  therefore  complex  Interfaces),  logic  and  failure  detection  and  reconfiguration  algo¬ 
rithms  la  not  as  mature  and  established  as  that  of  the  application  algorithms. 

4.0  PFVET/)PMENT  AND  VERIFICATION  OTTPELIWES  AND  FmORTTNC  FKVTROMMEir’ 

In  recent  years,  significant  progress  has  been  to  Improve  our  understanding  of  the  software  development 
and  verification  process,  'H^e  malor  result  has  been  to  move  the  emphasis  from  coding  to  design,  and  to 
enforce  methods  which  produce  simple*  easv  to  understand  software,  Fquallv  Important  has  been  the 


(^rtenolnatlon  that  th»  verification  proceaa  does  not  start  after  code  has  been  developed,  but  it  nust 
parallel  the  entire  development  effort  from  the  be(<lnnlng.  In  fact,  the  errors  moat  difficult  to  detect 
and  coatlv  to  remove  are  generated  during  the  earlv  phnaea  of  the  development  process,  as  prevtoualv 
discussed.  The  Importance  of  a  structured  development  and  verification  approach  la  particularly  felt  in 
the  case  of  aafetv  critical  applicstlona  like  flight  control  systems.  Much  documentation  exists  relative 
to  methods,  tools,  techniques,  and  environment  vhich  support  such  processes.  (Guidelines  for  mllltarv 
systems  sre  described  In  the  ?}o7>-‘5(TD*2167A  f5).  Corresponding  guidelines  for  commercial  svatems  are 
described  In  the  RTCA  document  RTCA/T)0-17flA  (6).  Both  documents,  define  sn  amount  of  development, 
verification  and  documentation  efforts  which  Increases  with  the  criticality  of  the  application,  and  both 
stress  the  importance  of  initiating  the  verification  process  at  the  earliest  phases  of  the  development 
process.  Figure  3  shows  the  progression  of  software  development  activities  and  the  corresponding 
verification  activities.  The  development  process  Includes  requirements  development,  design,  coding. 
Integration  and  system  test.  The  primary  aupportlng  documentation  to  be  produced  In  each  phase  Is  also 
shown. 

The  software  verification  sseuranc^  metrics  for  each  level  of  software  la  shown  In  Table  4.  It  la 
observed  that  the  rigor  and  formality  of  the  assurance  process  Is  the  most  demanding  fcr  critical 
functions  (LFVP.I.  I)  which  effect  flight  safety. 

The  existing  ViV  technology  lor  advanced  FCO-FBW  svatems,  must  be  continuously  enhanced  by  new  tools, 
techniques  nnd  methods  In  order  to  maintain  the  V&V  cost  within  reasonable  bounds,  ^ome  systems  require 
the  development  of  VAV  capabilities  rot  currently  available.  Aa  an  example,  the  verification  of  systems 
capable  of  performing  NOE  and  TF/TA  missions,  reoulres  the  availability  of  data  from  several  sensors 
which  cannot  be  realistically  produced  In  current  simulation  envlrornnenta.  Appropriate  techniques  must 
then  be  developed  ao  that  the  coat  effective  real  tine,  pllot-in  the-loop  simulated  environments  can 
still  he  an  essential  part  of  the  development  and  validation  process  of  those  svatems.  The  onlv  avsll~ 
able  alternate  approach  Is  to  validate  those  functions  entirely  bv  flight  testing,  which  Is  s  prohlbl- 
tlvelv  expensive  proposition. 

A  tvplcal  current  software  development  and  verification  process  Is  supported  bv  two  distinct  environ¬ 
ments.  The  first  environment,  unuallv  hosted  in  a  main  frame  or  mini  computer  operating  In  an  interac¬ 
tive  mode,  is  applicable  to  a  broad  category  of  digital  flight  system  (r»FS>  programs  and  provides  general 
purpose  capabilities  In  the  following  areas: 

1)  Control  Lavs  Analysis.  Tools  are  provided  which  support  tlesign  and  analysis  of  continuous  and 
discrete  contra’  a^^stems  using  classical  and  modern  cechnlaues.  An  example  Is  ^requencv  response  and 
root  locus  analysis  to  assess  the  performance  and  stability  of  classical  control  avstems.  In  the  case  of 
optimal  control  svatems,  eigenvalues/etgervector  analysis  is  used  for  the  same  purpose. 

3)  Reliability  and  Failure  Mode/Rffecte  Analysis.  Rellabillt'’  analysis  is  used  to  evaluate  the 
probability  of  a  svstem  to  successfully  perform  specific  tasks.  Failure  mode  and  effecta  analysis  (FMEAl 
establishes  the  effects  of  system  components  failures  on  overall  system  performance.  The  combined 
results  o'  the  two  analyses  is  to  ^’t^rify  that  anv  failure,  or  combination  of  failures,  which  could  have 
catastrophic  consequences,  has  onlv  a  verv  low  and  acceptable  prohabllltv  of  occurrence. 

3")  Software  Development.  Software  tools  support  several  software  development  tasks,  such  as 
software  design  and  documentation,  code  generation,  and  configuration  management.  The  cools  which 
support  the  critical  task  of  code  generation  are  required  to  he  very  mature;  compilers,  assemblers  and 
linkers  fall  in  this  category. 

The  second  environment  has  the  capahllttv  of  exercising  the  flight  software  in  real-time.  This  environ¬ 
ment  is  typtcallv  developed  for  and  dedicated  to  a  single  program.  It  Includes  essential  elements  of  the 
flight  control  system  (FCSl ,  and  the  airplane  dvnamics,  so  that  closed  loop  analvals  can  be  made.  Some 
FCS  components  are  simulated,  some  are  emulated  and  others  are  dlrectlv  included  in  the  environment. 
Typically,  the  flight  computer  hardware  Is  Included  so  that  flight  software  can  be  exercised  In  a 
representative  environment.  The  simulation  of  the  aircraft  dynamics  and  of  those  FCS  hardware  cotBponents 
that  would  be  impractical  to  Include  In  the  environment  are  Implemented  in  a  dedl«:ated  host  processor 
linked  to  the  flight  computers.  These  real-time  environments  olav  an  extremely  important  role  in  FCS 
development. 

The  entire  software  VfiV  process  is  affected  bv:  a)  the  earlv  selection  of  the  design  and  development 
approach,  and  b)  the  availability  of  advanced  tools  and  methods.  Both  topics  are  further  expanded  In 
the  following  sections  of  this  paper. 

5.0  DESICN  C0WSTPFRATI0K5 

The  software  issues  which  mostlv  af'ect  the  VAV  process  are:  a)  the  uae  of  high  order  languagea  CffOL) 
vs.  assembly  language;  bl  the  use  of  dissimilar  software;  and,  c)  the  methods  for  supporting  the  earlv 
phases  of  the  design  process.  They  are  discussed  further  In  the  foilcaring  paragraphs. 

5.1  FPL  vs.  ASSEMBLY 

The  use  of  HOL  is  Increasingly  accepted  In  flight  applications.  There  are  many  reasona  for  Increaalng 
use  of  HPT.: 

a)  Oompllera  are  getting  more  efficient.  The  memory  end  time  penalties  associated  with  the  use  of 
FPL  instead  of  assembly  are  becoming  smaller  (50T  and  20T  respectively'!,  and  less  significant  due  to 
Increasing  computational  speeds  and  decreasing  cost  of  memory. 

h)  There  is  a  strong  Indication  that  ROL  programs  sre  more  reliable  than  aasenblv  programs.  In  a 
studv  of  software  reliability  of  FCS  It  was  found  that  the  fault  density  of  FCS  software  written  in  WOt 
is  approximately  30F  of  that  of  assembly  program  (7), 


15-4 


r 


1 

i 


( 

t 


c)  FOL  prograu  are  aaaiar  to  davalop*  tast,  undaratand,  aodify  and  calntaln  than  aaaanbly  pro- 
graM. 

d)  Significant  axparlanca  la  nov  avatlahla  ralatlva  to  tha  perforaanca  and  the  code  generated  bv 
Mtura  software  tools*  like  coapllara*  aaaaablara  and  linkers. 

For  all  tha  above  raaaona  the  V&V  process  of  flight  software  la  slwpllfled  a  great  deal  If  the  prograna 
are  written  In  HOL  rather  than  asaawblv. 

5.2  DISSIMILAR  SOFTWABE 


Tha  purpose  of  using  dlaslallar  eoftwara*  In  redundant  configurations*  Is  to  prevent  cataatrophlc  conae-* 
quencaa  fron  a  coaaon*  undetected  error*  in  all  channels.  Dlaalaillar  aoftware  can  be  used  In  two  wavs: 

a)  As  a  failure  detection  nechaniaw  In  the  operational  ayatew.  In  this  case*  both  aoftware 
versions  execute  at  the  sawe  else.  The  results  ere  cospared  periodically*  and  in  the  case  that  the 
results  differ  by  sore  than  certain  values*  a  fault  condition  la  detected.  Tn  that  case*  reversion  to  a 
back-up  control  node  la  sLsde*  «rhlch  does  not  utilise  either  of  Che  two  software  versions. 

b)  As  a  back-up  control  node.  In  this  case*  if  a  cosson  failure  la  detected  in  the  prlnarv  soft¬ 
ware,  reversion  la  nade  to  the  alternate  version. 

5.3  THE  EARLY  PHASES  OF  THE  DEVELOPMKHT  PROCESS 


A  clear  evidence  exists  that  Che  software  errors  which  ere  sost  difficult  and  costly  to  detect  are  often 
Introduced  early  in  the  developaent  process.  This  points  to  the  reed  for  tools*  techniques  and  oethod- 
ologlea  capable  of  supporting  effectively  the  specification*  and  design  phases. 

It  la  excrenel V  Inportanc  to  define*  as  early  In  the  development  cvcle  as  possible*  design  disciplines 
which  make  the  software  traceable*  teatable*  maintainable  and  eaav  to  understand.  Design  and  coding 
standards  must  also  be  establlahed.  Exanplea  of  standards  connonlv  enforced  are:  a)  limiting  the 
nexlmum  alee  of  Che  smallest  aoftware  component*  the  module,  b)  avoiding  constructs  which  make  It 
difficult  Co  understand  and  verify  the  code,  like  unstructured  GO-TOs,  and  cl  providing  clear  and 
comprehensive  documentation  embedded  In  the  source  code  listings. 

6.0  ADVANCED  TOOTS  AND  METHODS 

The  techniques  described  In  this  section  address  some  of  Che  most  critical  technology  needa  In  the  areas 
of  system  architecture  design  and  analysis*  and  software  development  and  verification.  Thev  are  intended 
to  he  integrated  with  existing  and  new  technologies  In  cost  effective  and  easv  to  use  environments. 

6.1  SYSTEM  ARCHTTFCTURE  ANALYSIS 


The  selection  of  a  DFS  configuration  is  the  result  of  difficult  compromises  among  several,  and  often 
contrasting  requirements  and  constraints.  The  designer  needs  tools  for  slmulaflng  and  analysing  the 
relative  merits  of  competing  configurations*  very  early  In  the  development  cycle*  prior  to  committing  to 
any  specific  configuration.  Two  different  methods  of  analysts  are  proposed.  The  first  method*  Is  based 
on  the  complexity  analysis  of  the  topography  of  the  architecture*  and  of  the  corresponding  structure  of 
the  software.  The  second  method*  is  based  on  a  non  real-time  simulation  of  the  operational  performance 
of  the  system  under  a  variety  of  environmental  conditions. 

6.1.1  COMPLPXITT  METRICS 

Complexity  metrics  can  support  software  code*  aoftware  design  and  system  architecture  analysis.  An 
approach  la  the  graph  theory  based  McCabe's  metrics*  which  calculates  a  Cyclomntlc  Number  (CN^  from  the 
difference  between  the  number  of  nodes  and  the  number  of  edges  (B).  A  node  la  a  straight  line  segment  of 
code*  a  functionally  cohesive  aoftware  module  or  an  hardware  embedded  function*  In  case  of  software  code* 
software  design,  and  avstem  architecture  analysis*  respectively. 

When  the  McCabe's  model  Is  applied  to  DFS  architectures*  the  real-time  execution  of  the  software  embedded 
in  each  processor  must  be  considered.  Factors  which  must  be  considered  Include: 

a)  Flight  aoftware  executes  at  different  rates*  depending  on  the  dynamics  of  the  control  algo¬ 
rithms. 

b)  Advanced*  multimode*  flight  control  systema  perform  different  trsks  depending  on  the  aircraft 
flight  and  nlaalon  mode, 

c)  Some  low  priority  application  modules  can  be  Interrupted,  which  Increaaea  the  comnlexitv  of  the 
control  flow. 

d>  Distributed  Architectures  which  have  a  degree  of  complexity  higher  than  a  single  processor 
architecture  because  they  require  additional  communication  for  exchanging  data,  time  synchronization* 
fallura  detection  and  reconfigtiratlon. 

The  architecture  and  software  complexity  metrics  ere  static  tools  which  cen  be  applied  throughout  svstem 
design  phases  In  a  manner  that  penstte  the  inclusion  of  more  design  details  as  thev  become  evallahlc. 

They  can  be  effectively  utilised  during  the  eerlv  development  phases  for  compering  coirpetitive  architec¬ 
tures  and  analvslng  the  effects  of  design  modifications. 
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6.1.2  SIMULATION  TgCHNIOUES 


Another  iaportant  neesure  of  the  ouellty  of  the  architecture  can  he  achieved  frnir  dynamic  parameters  such 
as  the  distribution  of  the  computation  load  amonp  processors,  the  utilization  of,  and  competition  for, 
shared  resources  such  as  coson  busses,  and  other  time  sensitive  parameters.  The  parameters  can  be 
estimated  by  simulating.  In  a  non  real-time  environment,  the  relevant  sem^t'^ces  jf  tasks  to  he  performed, 
and  by  keeping  crack  of  Che  Cine  needed  by  the  allocated  resources  ro  perform  those  tasks.  To  eenerste 
this  dsta,  the  environment  must  be  able  to  simulate:  procedural  processes,  such  as  the  hlghlv  structured 
flight  control  algorithflis  which  execute  under  rigid,  predetermined  time  sequences;  parallel  processing, 
as  in  the  case  of  redundant,  distributed  configurations;  shared  resources,  such  as  coimnon  busses;  and  the 
executive  logic  which  controls  the  execution  flow  within  each  processor  in  those  cases  which  reoulre 
detailed  analysts  of  the  time  sequences  of  events  .  The  output  of  these  performance  simulation  runs  are; 
statistics  of  resource  utlllzerlon  and  detailed  tine  sequence  events  like  the  exact  timing  of  data 
exchange  among  redundant  processors. 

Host  of  the  eleisents  included  In  the  performance  simulation  environment  lust  described  have  been  devel- 
oped  for,  and  effectively  used  In,  application  auch  as  Command,  Control  and  Cowunlcatlon  (9).  This  tvpe 
of  simulation  baa  not  been  applied  to  CPS  because  of  the  relatively  simple  configuration  structures  of 
current  systems.  On  the  other  hand,  the  architectural  complexities  of  the  next  generation  PFS  iustifles 
the  need  for  those  capabilities. 

The  sisulstlona  and  the  complexity  metrics  tools,  described  in  this  section  the  paper,  car  be  hosted 
In  the  same  environments  which  currently  support  control  lav  development  and  analvals,  and  software 

development. 

6.2  SOFTWARE  VERIFICATION 


Software  la  often  the  most  critical  element  In  terms  of  development,  verification  and  maintenance  cost, 
and  software  ie  a  major  contributor  to  the  overall  failure  rate  of  current  DFS.  The  current, 
state-of-the-art ,  software  teat  strategies  are  structured  to  exercise  all  Indenendent  software  logical 
paths  with  a  minimum  set  of  test  data.  A  removal  of  all  implementation  faults,  however,  cannot  he 
guaranteed  even  if  1002  test  coverage  Is  achieved.  In  fact,  failures  can  still  occur  as  a  result  of 
unusual  logical  or  timing  sequences  of  events.  Then  If  one  of  these  combinations  should  occur  in  flight, 
a  system  fsllure  could  result  with  unpredictable  consequences. 

To  achieve  a  high  level  of  confidence  that  all  the  failure  trlggerlns  combinations  are  detected,  a  stress 
test  technique  la  described  which  Is  a  highly  automated,  very  effective  wav  to  test  code  with  an  extreme¬ 
ly  large  number  of  teat  data  sets  while  it  Is  executing  in  the  target  processorfs) .  Several  properties 
of  the  software  can  be  stress  tested,  among  them:  the  computational  algorithms,  the  timing  requirements 
and  the  partitioning  existing  among  modules  of  different  rrltlcalltv.  These  topics  are  discussed  in  the 
following  paragraphs. 

6.2.1  DATA  STRESS  TEST 

This  test  verifies  the  correct  algorithmic  execution  of  a  software  application  functions  HO).  Examples 
are  the  numerical  Intensive  algorithms  like  those  Implementing  guidance  end  controls  laws,  and  logical 
intensive  algorithms,  like  those  found  in  fault  detectlon/lsolatlon  and  system  reconfiguration. 

The  essence  of  this  teat  Is  to  execute  critical  software  functions  In  the  target  computer  rcncurrentlv 
with  the  execution  of  alternate  benchmark  versions  In  a  host  machine.  The  benchmark  is  coded  directlv 
from  the  design  document.  The  same  exhaustive  Input  sequence  of  data,  within  and  outside  the  specifica¬ 
tion  boundaries  of  each  function,  nre  then  used  to  exercise  both  Implementations  at  the  same  time.  Then 
errors  in  either  implementatlor  will  result  in  different  outputs,  under  certain  test  conditions,  because 
It  is  extremely  improbable  that  the  same  errors  are  made  In  both  versions.  Because  of  the  extremely 
large  number  of  test  data  involved,  It  Is  necessary  to  automate  the  entire  stress  testing  process. 

6.2.2  TIMING  STRESS  TEST 

This  test  measures  the  statistical  distribution  of  the  computational  and  transport  delava  between  the 
time  variables  are  set  in  one  processor  and  the  time  thev  are  used  In  other  processors;  and  It  verifies 
that  the  delava  do  not  exceed  predetermined  maximum  values. 

The  two  main  factors  to  be  considered  tn  the  application  of  this  test  are: 

al  Tntraprocessor  Delav  -  The  computational  delava  between  the  time  the  updated  values  of  variables 
are  svaltsble  within  a  processor,  and  the  time  the  outputs  of  the  algorlthr>s  using  those  variables,  are 
actually  computed.  This  delay  is  a  function  of  the  computational  logic  path,  within  the  processor,  which 
can  vary  from  iteration  to  Iteration.  Software  multlrste  structures,  changes  of  aircraft  flight  mode  or 
cockpit  display  mode  end  changes  of  some  parameters  values  can  affect  these  delays. 

b)  Interproccssor  Delay  -  The  transmission  delev  between  two  processors  Including:  1)  the  computa¬ 
tional  delay  between  the  tine  the  output  of  an  algorithm  le  updated  within  a  proceseor  and  the  execution 
of  the  output  etatemente;  and  2)  the  time  needed  to  transfer  the  actual  data  from  the  output  buffer  of 
one  processor  to  the  Input  buffer  of  another  processor.  Inclusive  of  any  buffer  access  and  transmission 
times.  These  componente  vary  as  a  function  of  the  execution  paths  of  the  two  proceseore  and  of  the 
avslleblllty  of  sharsd  resources  such  as  hue  interfaces. 

The  ultimate  oblcctlve  of  timing  etreae  test  le  to  determine,  for  each  time  critical  variable,  the 
distribution  of  computational  and  tranaport  delays;  and  verify  that,  under  no  eltuatlon,  those  delays  do 
not  excaed  predetermlnad  maximum  values.  The  entire  process  of  time  etreeelng  can  be  easily  automated 
using  the  same  environment  which  supporte  data  atress  test  <I0>. 


6.2.3  PAKTITIONIWG  STRESS  TEST 


This  tsst  verlflsa  the  partitioning  between  two  funetlons.  Function  "A"  Is  partitioned  frow  If  not* 
action  of  function  '*B'*  can  cause  a  failure  of  function  "A".  The  need  for  this  test  derives  frow  two 
considerations:  1)  OFS  configurations  Include  functions  and  conponents  of  different  levels  of  crltlcall'> 
tji  and  2)  the  required  devalopwent  effort  and  deveSopwent  cost  vary  a  great  deal  as  a  function  of  the 
criticality.  If  partitioning  cannot  be  dewonatrated  between  function!  "A"  and  **1**  with  different  levels 
of  criticality  then  both  funetlona  wuat  be  considered  aa  having  tha  aanc  level  of  crltlcalltv  which  le 
the  highest  betwaan  lavela  "A"  and  "B".  This  unduly  Inereaaaa  tha  developwant  and  verification  coat  of 
the  functions  which  have  the  lowest  Intrinsic  criticality  lavel. 

The  objective  of  partitioning  atraaa  test  Is  to  dewonstrate  partitioning  between  two  functions  of  differ¬ 
ent  levels  of  criticality.  To  achieve  this  oblectlve  it  wust  be  dewonatrated  that  no  output  data  frow 
the  least  critical  function*  and  no  tlwe  abewness  between  the  execution  tlwes  of  the  two  functions*  can 
cause  a  failure  of  the  sosc  critical  function. 

The  currently  used  real-tine*  dedlceted  envlronwent  which  includes  the  target  conputers  and  embedded 
software  la  an  Ideal  host  for  the  stress  technlquss  previously  described.  Bequlrewents  ere  that  the 
software  under  test  execute  under  conditions  which  are  representative  of  the  flight  conditions. 

7.0  CONCLUSIONS 


The  software  characteristics  and  the  existing  guidelines  for  the  development  end  verification  of  flight 
critical  syacepe  have  been  described.  The  technology  requirements  for  flight  critical  systems  for  the 
next  generation  of  slrcrafc  have  also  been  anslvsed.  Major  technology  needs  have  been  identified  in  the 
areas  of  sysrem  architecture  design  and  software  development.  Two  methods  to  aatiafy  these  reoulrements 
are  described  which  can  be  highly  automated  and  can  be  Integrated  with  an  existing  develonment  environ¬ 
ment.  The  first  method  leads  to  a  quantitative  assessment  of  the  quality  of  competing  svstem  erchltec- 
turea.  The  second  methods  can  be  utilited  for  testing  some  critlcel  software  requirements  with  erfremelv 
large  sets  of  teat  data.  Both  methods  have  the  promise  of  significantly  enhancing  the  technical  capabil¬ 
ity  of  the  existing  development  and  verification  procedures  and  of  reducing  the  life-cycle  costs  of  the 
next  generation  FCD-FBU  systems. 
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Table  2.  Table  3. 


MEMORY  REQUIREMENTS  FOR  FCS  SOFTWARE  FCS  SOFTWARE  ERROR  DISTRIBUTION 


SOFTWABE 

FUNCTIONS 

MEMORY 

REQUIREMENTS 

ERROR  CATEGORY 

FREQUENCY 

APPLICATION 

25% 

COMPUTATIONAL 

10% 

LOGIC 

20% 

LOGIC 

25% 

TESTING 

20% 

DATA  HANDLING 

35% 

I/O  &  EXECUTIVE 

20% 

INTERFACES 

10% 

MISCELUNEA 

15% 

MISCELLANEA 

20% 

TOTAL 

100% 

TOTAL 

100% 

Table  4.  SOFTWARE  VERIFICATION  ASSURANCE  MATRIX 
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VERIFY  SOFTWARE  REQ. 
vs.  SYSTEM  REQ. 

X 

X 

X 

VERIFY  DESIGN  vs. 

SOFTWARE  REQ. 

X 

X 

X 

VERIFY  CODE  vs. 

DESIGN 
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DISCUSSION 


A.O.Wai^UK 

Do  you  know  of  any  projects  that  have  ^opted  Ada  for  safety  critical  systems? 
Author’s  Reply 

I  am  not  aware  of  any  current  production  flight  critical  systems  which  are  utilizing  Ada. 


J  J^Xocroix,  Fr 

Do  you  agree  that  strftware  dissymetry  sikHild  be  extended  to  development  and  include  two  different  teams? 

Author’s  Reply 

The  utilization  of  dissimilar  software  is  a  means  for  improving  the  fault  tolerance  of  the  software  within  the  system.  The 
use  of  two  independent  development  teams  would  greatly  improve  the  reliability  of  the  fault  critical  system  if  the 
process  was  in  fact  independent.  This  implies  that  indep^ent  specifications  are  developed  since  independent 
development  using  a  common  requirement  could  carry  the  same  design  errors  through  both  systems.  Althou^  the  two 
independent  development  teams  approach  was  an  advantage,  however,  the  cost  would  probably  prohibit  its  use. 


WJVUnaeltGe 

When  using  HOL  for  flight  critical  software*  a  verificaticm  of  the  compiler  has  to  be  considered.  Do  you  assume  that  this 
is  covered  in  your  verification  by  the  code  verification  process  which  also  includes  the  verification  of  the  run  time 
system? 

Authror*!  R^ily 

brrors  introduced  by  compilers  have  always  been  a  concern.  However,  in  our  experience,  although  limited  at  the 
present  time,  we  have  not  found  this  to  be  a  probl«n.  The  rigorous  V&  V  process  used  for  these  systems  has  detected 
compiler  errors  and  permitted  correction. 


Otti4«itn«*  for  BvoluAtlon 
of 

Softvoro  Saglaoorlng  Tool* 


ftobort  B.  lfem*l«tolii»  ILC.  VSAt 
Coaputor  E*«oorch  BclMfclat 
U9At/AAAf-2 
ffPAFB,  OH  45433.  DBA 


I.  Introduction 

For  batter  or  worse,  the  way  ailltary  software  Is  developed  and  nalntalned  will  undergo 
drastic  changes  In  the  next  decade.  This  Is  a  foregone  conclusion  since  oosC  nations  cannot 
afford  the  status  quo.  "Annual  software  costs  for  major  defense  systems,  which  were  at  about  $4 
billion  In  1980,  are  now  at  approximately  $10  billion,  and  are  expected  to  reach  $30  billion  by 
Che  early  1990s."  {1}  This  projection  is  driven  by  the  Increasing  need  for  software  In  weapons 
systems,  as  well  as,  the  Increasing  cost  of  developing  and  maintaining  this  code. 

The  cost  of  software  has  forced  the  tJSAF  to  explore  new  types  of  progreonslng  environments 
to  develop  and  maintain  software.  "A  programming  environment  Is  the  hardware  and  software 
required  to  support  software  life  cycle  activities.  These  life  cycle  activities  include  concept 
definition,  requirements  analysis,  preliminary  design,  detailed  design,  program  development, 
software  integration,  system  integration  and  testing,  and  maintenance."  [2]  A  typical 
programming  environment  consists  of  cools  which  are  used  in  combination  to  develop  software;  a 
barebones  environment  consists  of  a  text  editor,  compiler,  linker,  and  a  debugger.  In  the  last 
few  years,  USAF  interest  has  spawned  the  developisent  of  software  engineering  Cools  to  address 
every  phase  of  Che  programming  lifecycle  (£rcm  requirements  analysis  to  maintenance).  Although 
these  Cools  represent  an  important  step  in  automating  the  software  lifecycle,  there  is  often 
confusion  surrounding  the  selection  of  the  proper  tool  for  a  user's  application.  This  often 
results  in  cools  being  selected  %fhich  does  not  properly  meet  the  user's  needs.  The  principal 
causes  of  this  situation  are: 

*•  The  capabiliCies  of  the  tool  are  incoiq>lace  or  inadequate. 

•  «  The  choice  of  e  tool  is  premettxre. 

••  Problems  arise  with  tool  portability. 

--  The  tool  is  overly  complex. 

••  The  cool  is  not  robust. 

Because  the  mandated  use  of  an  inadequate  software  engineering  tools  in  the  software 
lifecycle  can  have  devastating  effects  on  program  costs,  the  need  for  a  taxonomy  to  evaluate 
these  tools  is  readily  apparent.  This  taxonomy  should  contain  guidelines  which  are  applicable 
to  Che  design  of  a  new  tool  or  Che  selection  of  an  existing  one.  This  paper  will  define  a  basic 
taxonomy  for  evaluating  software  engineering  tools. 


II.  Description  of  the  Interactive  Ada  Vorkstatlon 

The  Interactive  Ada  Workstation  (lAH)  is  a  prototype  programming  environment  for  the  Ada 
language.  It  combines  a  number  of  state-of-the-art  capabilities  such  as  graphical  design 
techniques,  automatic  code  generation,  incremental  code  analysis,  incremental  debugging,  and 
reusable  software  aids  in  order  to  significantly  Increase  the  productivity  of  the  average 
prograMsr.  The  lAV  is  hosted  on  a  Symbolics  3670  Lisp  fUchine;  this  host  was  chosen  for  Us 
to  specify  the  top  level,  data  flow  design  of  his  program.  The  design  is  expressed  in  terns  of 
icons  which  represent  packages,  subprogram  units,  data  types  and  their  interfaces.  From  this 
deecription,  the  corresponding  Ada  code  will  be  genereted. 

b.  State  Machine  Editor:  The  purpose  of  this  editor  is  to  provide  the  progremmer  with  the 
ability  to  specify  the  top  level  control  flow  for  a  particular  subprogram  unit  (task,  procedure 
or  function).  The  design  is  expressed  in  terms  of  states  (representing  specific  actions  to  be 
taken)  end  transitions  (representing  control  flow  decisions)  between  states.  Once  e  design  has 
been  generated,  the  programmer  can  use  a  simulator  to  test  his  model.  This  description  can  be 
used  to  generate  the  Ada  coda  template  for  the  desired  subprogram. 

c.  Decision  Table  Editor:  This  editor  has  the  seme  general  purpose  as  the  State  Machine 
editor,  however,  it  makes  use  of  a  different  design  methodology  to  accomplish  Its  purpose.  The 
Decision  Table  editor  (DTE)  allows  the  programmer  to  define  rules  and  attach  specific  actions  to 
them.  The  Decision  Table  editor  has  a  tabular  spreadsheet  format,  rather  than  the  Icon  based 
format  of  the  BEAT  and  State  Machine  editors.  Like  the  previous  editors,  the  DTE  can  generate 
the  Ada  coda  corresponding  to  its  description. 

d.  ZAda  Editor:  The  lAda  editor  Is  a  syntax  directed  editor  for  the  Ada  programming 
language.  Its  purpose  is  to  give  the  programmer  the  capability  to  fill  in  the  code  templates 
generated  by  the  graphical  editors.  The  lAda  editor  will  also  perform  Incremental  syntax  and 
semantic  analysis  on  tha  Ada  code  within  Its  text  buffer  (syntax  errors  ere  isnediately  flagged 
with  Inverse  video  in  the  text  buffer  end  semantic  errors  ere  logged  in  a  leparste  window).  The 
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lAda  editor  will  build  «n  IntemAl  reprwMnCacion  of  cho  prograa  (called  IFoni)  as  ic  !•  being 
Increaentally  analyzed.  Once  che  Ada  prograa  has  been  vrlcten  using  this  edlcor,  Che  prograoner 
can  Chen  regenerate  Che  updated  BSAT  dlagraa  fro«  Che  IFen.  In  future  versions  of  Che  lAda 
editor  an  interpreter  will  be  provided  to  allow  the  programer  co  test  his  code. 

The  purpose  of  the  lAU  program  was  to  provide  a  proof -of -concept  that  these  state-of-the- 
arc  prograaning  techniques  could  be  inpleaented  together  on  a  high  perfomance  engineering 
workstation.  As  a  result  of  this  prograa.  General  Electric  (developers  of  the  lAW)  have  ceaiaed 
with  Cadre  Technologies  to  narket  che  lAtf  as  a  product.  The  lAU  project  also  gave  AFUAL  a 
considerable  aiaounC  of  insight  into  che  attributes  an  advanced  progranmlng  enviromaent  should 
have. 


III.  Evaluation  Methodology 


a.  Rost  Cosputer  Considerations 

The  selection  of  a  host  conputer  is  one  of  che  nose  laporcant  decisions  to  oake  concerning 
the  developnenc  of  sofeware.  This  section  will  explore  sone  of  the  raniflcatlons  of  host 
coarputer  selection  upon  prograoner  productivity. 

(1)  Cose 

The  cost  of  che  host  systen  should  not  be  prohibitively  high  in  terns  of  a  cost/user  ratio. 
The  advent  of  powerful  personal  cosqmters  and  engineering  workstations  gives  che  individual 
increased  coapucing  power  at  considerably  less  expense.  A  Sun  3/50  Workstation  (which  is  based 
on  a  Motorola  68020  processor  running  ac  16MHz)  can  be  purchased  for  under  $8K.  As  a  result, 
these  systems  are  becoming  increasingly  popular.  A  figure  of  $7 , 500/prograimier  is  a  reasonable 
cost/user  ratio. 

(2)  Vendor  Support 

The  host  computer  vendor  must  be  available  to  give  adequate  support.  The  software 
developer  should  be  concerned  about  support  in  the  areas  of  user  support  (documentation,  hot¬ 
lines,  etc),  sofeware  support  (availability  of  quality  software  and  documentation),  and  hardware 
maintenance  (quality  and  timeliness  of  system  maintenance).  Without  proper  vendor  support  even 
a  state-of-che-arc  computer  can  quickly  become  obsolete. 

(3)  Availability 

Availability  can  be  viewed  in  two  ways.  The  first  is  availability  within  an  organization. 
A  prograaning  tool  will  not  improve  productivity  if  personnel  have  Co  wait  in  line  to  use  it. 
Availability  Is  one  of  the  greatest  benefits  of  Cionsharing  computer  systems.  Individual 
workstations  (such  as  the  Sun)  lose  their  appeal  if  there  is  a  high  user/machine  ratio.  The 
second  way  of  looking  at  availability  is  how  widespread  is  the  use  of  a  given  system.  A  host 
system  which  is  powerful,  but  quite  expensive  (a  Lisp  Machine,  for  example)  will  not  be 
available  in  volume  to  other  organizations.  This  limits  the  ability  of  the  software  developers 
to  transition  a  program  once  it  has  been  developed  on  a  specific  environment. 

(4)  Host/Target  Computer  Relationship 

The  number  of  computers  needed  for  software  development  should  be  limited  as  much  as 
possible.  Ideally,  the  host  and  target  cmiputers  will  be  one  In  the  same.  This  simplifies 
software  development  and  testing  considerably.  In  many  embedded  applications ,  however,  the  host 
and  target  computers  are  separate.  The  host  computer  will  normally  have  an  editor  and  cross 
compiler  along  with  some  means  of  downloading  the  executable  image  to  the  target  processor.  The 
target  system  will  typically  have  a  monitor  program  running  to  allow  for  debugging  of  the 
application.  Many  cross  compilers  for  embedded  target  processors  are  hosted  on  super 
minicomputers  (like  the  VAX  11/780). 

In  contrast,  many  object  oriented  programing  tools  require  expensive  user  interaction, 
windowing,  and  graphics  capabilities;  this  is  beyond  the  scope  of  most  timesharing  systems.  As 
a  result,  these  tools  ere  designed  for  systems  which  can  be  dedicated  to  the  individual 
prograimier  (like  the  Sun  Workstation  and  the  IBM  PC/AT).  Since  these  systems  usually  do  not 
support  cross  compilation,  the  progremer  must  now  dsslgn  his  program  on  one  host,  compile  it  on 
another,  and  debug  it  on  a  third.  The  extension  of  the  software  development  process  to  three 
different  systems  introduces  considerably  more  overhead;  this  can  be  especially  taxing  on  a 
small  progranoilng  team  with  a  deadline  to  meet.  In  this  situation  tools  which  are  supposed  to 
increase  software  productivity  may  become  mre  of  a  burden  than  a  boon  to  development. 


b.  Portability 

The  Importance  of  producing  portable  software  Is  becoming  Increasingly  recognized.  As  the 
cost  of  software  increases,  it  becomes  desirsble  to  only  write  a  piece  of  software  which  can  be 
uaed  on  mai^  different  systems  with  little  or  no  modification.  This  section  provides  Insight 
into  the  why  a  tool  should  be  portable  and  how  this  esn  be  achieved. 
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(I)  R«tlon«l« 

It  is  crlticsl  th«t  eh«  Intended  scop«  of  tool  ussgo  bo  daftned  baforo  tho  dosign  of  a  tool 
or  tho  soloction  of  an  existing  ono  for  prograa  dovolopaont.  There  are  three  naln  levels  of 
portability;  these  are: 

••  Portable  to  a  specific  configuration. 

-•  Portable  to  a  specific  cIsmm  of  sMcbines  fsuch  as  the  IBM  BC,IT,  and  AT). 

•  •  Portable  to  Machines  with  different  architectures. 

Depending  on  the  viewpoint,  the  need  for  portability  will  take  on  different  levels  of 
urgency.  The  tool  developer  nay  want  to  Make  his  product  as  portable  as  possible  In  order  to 
take  advantage  of  a  broader  aarket  (both  existing  and  potential).  On  the  ocher  hand,  he  say 
decide  CO  tailor  his  product  for  each  systea.  thereby  taking  advantage  of  capabillClea  xmlque  Co 
Chat  aystea.  Although  tha  applleaclona  progrsaasr  aay  not  ba  initially  concerned  about  tool 
portability,  here  are  aoae  reaaone  why  portability  aay  becoae  algnlfleant: 

•  •  The  organisation  aaintalnlng  the  software  aay  not  have  the  saae  host  coa^uter 
conflgurscioti  as  the  orlginMl  progrsaasr.  As  s  rssult,  the  software  swlntenance  people 
will  not  hsvs  access  to  tools  which  served  es  en  integral  part  of  the  design. 

-•  Poutine  repiaceSMnt  of  e^uipaent  asy  msks  snj  tools  purchsssd  obsolete.  This  is 

especially  Imporesnt  whsn  ons  c^'^idsrs  Che  lifeciae  of  a  weapons  systen  compared  to 
that  of  s  coi^ucer  systea. 

*'  (Upgrades  to  operating  systems  asy  slso  cause  tool  degradation. 


(2)  Portability  Conslderaclona 

There  are  several  factore  which  deteraine  the  potential  portability  of  any  given  cool. 
These  fall  into  three  main  categories;  these  ere  hardware,  language,  and  operating  systen  usage. 

Perhaps  the  oost  inportanc  deceminanc  of  a  tool’s  portability  is  how  it  interfaces  with 
the  hardware  of  Its  host.  Truly  portable  code  will  have  the  following  attributes; 

•'It  will  be  written  in  s  high  level  language. 

It  will  access  peripherals  through  opsrstlng  systen  shell  cells,  not  directly 
••  It  shell  not  mske  use  of  special  bosrds  specific  only  to  one  configurstion. 

The  amount  of  memory  required  to  runthe  spplicstion  should  not  be  beyond  the 
addressing  cspsbillty  of  any  Machine  in  e  given  class. 

In  sone  cases,  tho  use  of  conflgurotion  specific  codie  say  be  iinavoidsble.  In  this 
situation,  all  systan  dependent  routines  should  be  isolated  into  separate  packages.  These 
routines  should  be  docuoMnted  to  include  purpose,  re<lulreBent8 .  flowcharts;  evphasls  should  be 
placed  on  details  of  the  interface  with  the  underlying  hardware. 


The  prograsnlng  language  used  to  Inpleaent  the  design  tool  Is  also  extceaely  inportanc. 
Although  ualng  aaaenbly  language  helps  the  tool  designer  to  optlnlse  its  perfomence,  it  also 
ainlnizes  portability  and  results  In  cryptic  code.  Using  e  high  level  language  has  the 
advantage  of  letting  the  conpller  worry  about  potential  systen  dependenclee  such  as  different 
types  of  addressing.  The  use  of  a  hl^  level  language,  however,  does  not  absolutely  guarantee 
portability.  If  the  progrannlng  language  Is  obscure,  conpller  eveilabllity  on  host  systens  nay 
be  lacking.  It  is  also  Inportanc  to  Insure  Uiat  varletlons  in  the  language  pn  different  systens 
ars  nininlzed.  Although  conpllers  for  a  given  langiuage  exist,  there  nay  be  variations  both  In 
the  conpller  quality  and  the  language  Itself  across  different  host  conputere.  A  language  which 
enploys  a  standard  (such  as  Ada)  should  help  to  guarantee  sone  level  of  language  Integrity. 
Ideally,  conpller  vendors  should  support  nultlple  architectures  with  the  sane  front  end  to  their 
conpller. 

The  choice  of  operating  systen  also  influences  portability.  The  operating  systen  provides 
services  idilch  allow  tha  spplicstion  progran  to  interfaca  to  the  underlying  hardware.  The 
flexibility  of  the  operating  systen  will  detemlne  if  systen  dependent  routines  are  necessary 
for  tool  developnent.  If  a  progranning  tool  ia  being  developed  soley  for  a  specific 
configuration  then  syeten  specific  routines  can  be  used  with  inpunlcy.  A  good  exsaple  of  this 
Is  Che  window  syeten  evellsble  on  the  Synbollcs  3600  series  machines.  The  window  systen  enables 
the  progransMr  to  create  an  array  of  custonltad  windows  and  nanus  with  relative  ease. 
Unfortunately,  however,  there  le  no  standard  Lisp  window  systen  so  the  code  produced  Is  not 
portable  between  different  Inplenentatlons  of  Lisp. 

The  popularity  of  a  given  operating  eystea  la  directly  related  to  the  portability  of  a  tool 
which  Is  built  on  top  of  it.  If,  for  exanpla.  NS  DOS  Is  used,  the  tool  should  be  portable 
between  a  given  claas  of  computer  (like  the  IBM  PC);  or  if  Unix  la  enployed,  the  tool  nay  even 
be  portable  between  different  architectures.  In  addition.  It  Is  l^ortant  that  when  calls  are 
nade  to  other  progranmlng  shells  that  some  standard  exists  for  that  shell.  A  good  exsnple  Is 
Che  use  of  the  Graphics  Kernel  Standard  (GKS)  In  order  to  produce  graphics  support  for  s 
portabla  application.  The  Isoletlon  of  hardware  dependencies,  use  of  a  standardised  high  level 
language,  and  the  use  of  an  operating  systen  colon  to  several  archltecturea  are  three  factors 
which  oust  be  used  in  conblnatlon  in  order  to  insure  tool  portability. 
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c.  VMbllicy 

Ihi«  ««celi>n  •xjnln*a  tho««  4sp«ctii  of  «  progroMlns  tool  vhlch  Influonco  tho  effoctivenets 
of  tho  onvtrnwoot  os  o  oholo. 

<1)  Ovoroll  SystoB  Consldorotions 

A  softworo  onglnoorlng  tool  Is  only  o  subsoc  of  s  total  progroailng  enviromont. 
Accordingly,  tho  usofulnoss  of  ny  liMllvlduol  tool  will  bo  govomod  by  tho  ovoroll  quality  of 
its  onvironaont,  dospito  its  stand  olono  norlt.  In  ordor  to  addross  this,  the  following 
criteria  which  should  bo  consldorad  \itMn  designing  or  selecting  a  particular  tool. 

Tho  programing  onvironnont  should  bo  nodular  and  oxtondibla.  Tho  addition  of  now  tools 
should  not  degrade  tho  porfomanco  of  tho  onvlronnonc.  Docunontatlon  should  exist  concerning 
intarfacoa  bocwoon  cools.  In  addition,  syscoa  services  (such  as  windowing  and  user  interface 
routines)  should  bo  placed  in  comon  packages  and  nado  accessible  to  all  tools  In  the 
envlronBont . 

The  toolset  in  tho  enviromont  should  bo  functionally  integrated.  The  lAU  illustrates  this 
concept  by  using  diverse  design  tools  to  produce  code  for  a  cmaon  progran.  In  this  way  the 
Cools  work  as  a  sec,  not  as  stand  alone  cooponents. 

A  centralized  database  should  exist  to  share  prograa  Infomatlon  between  tools.  For 
exsaple.  Che  programer  nay  have  the  ability  to  review  the  PDL  of  the  code  he  was  modifying  from 
any  given  design  tool.  All  such  tools  should  have  sccess  to  the  shared  PDL  database.  These 
databases  should  be  treated  essentially  as  data  structures.  Operations  upon  these  data 
structures  should  be  fomally  defined.  Additionally,  these  operations  should  be  created 
essentially  as  system  calls  by  Che  requesting  cool. 

the  environment  should  have  a  standardized  user  interface.  The  user  interface  should  be 
easy  to  learn  for  the  beginner  (as  are  menu  driven  systems)  yet  It  should  not  slow  down  the 
expert.  A  typical  compromise  Is  to  make  either  a  keyword  or  menu  driven  mode  evallable  to  the 
programmer.  This  will  let  the  user  proceed  at  his  own  pace. 


(2)  Design  Tools 

The  Interactive  Ada  Workstation  prototypes  gave  AFWAL  considerable  insight  into  the  the 
attributes  of  quality  software  engineering  cools.  The  emphasis  of  the  lAU  was  on  tools  to  aid 
in  program  deaign  and  coding.  The  resulting  lessons  learned  are  eummarlzed  in  the  following 
paregrapha . 

The  design  Cools  should  integrate  a  number  of  different  techniques.  Each  design  technique 
has  its  strong  and  weak  points  when  expressing  different  classes  of  problems.  For  example,  a 
Buhr  diagram  editor  Is  very  good  at  expressing  data  flow,  but  does  not  touch  on  control  flow. 
Additionally,  a  State  Machine  editor  is  sn  excellent  way  of  expreeslng  sequential  control  flow, 
but  does  not  provide  for  concurrent  communicetion  between  processes.  Eeceuse  each  model  has  its 
own  particular  strong  or  weak  point,  it  Is  important  for  the  programmer  to  be  able  to  exploit 
them  eppropriecely. 

The  design  tool  should  support  automatic  generation  of  source  code.  If  each  design  tool  is 
to  represent  e  different  methodology,  it  is  important  that  the  code  generated  by  each  be  a  code 
shell.  This  shell  will  represent  the  data  flow  or  control  flow  algorithm  described  using  the 
tool,  but  should  have  room  to  let  the  user  fill  In  flK>ire  specific  details  using  e  text  editor. 
For  example,  e  state  in  the  State  Machine  editor  could  represent  either  a  code  block  or  e 
subprogram  call.  If  a  code  block  is  represented,  then  the  generated  code  should  Insert  a 
placeholder  which  can  be  replaced  with  source  code  at  a  later  time.  In  addition,  each  graphical 
design  tool  should  operate  off  of  a  shared  program  database  accessible  to  the  other  tools.  As  a 
result,  the  representation  of  the  code  will  be  consistent  between  different  views  of  the 
program . 

The  design  tools  should  have  support  for  low  level  language  constructs.  With  the  edvent  of 
eutomatic  code  generation,  the  distinction  between  design  and  coding  Is  becoming  increasingly 
fuzzy.  In  addition,  the  progreMer  will  often  try  to  take  advantage  of  specific  language 
features  (such  as  tasking  In  Ada)  at  the  design  level.  While  generic  design  tools  will  be 
composed  of  a  subset  of  features  shared  by  many  languages,  they  will  frustrate  the  progrsmmer 
trying  to  write  software  In  a  specific  language.  As  e  result,  the  progremmer  will  probably 
discard  the  design  tool  in  favor  of  the  familiar  text  editor.  In  eddition,  making  the  design 
tools  language  specific  will  also  improve  the  quality  of  automatically  generated  code. 

There  should  be  a  mechanism  to  expose  inconsistencies  in  the  design.  A  problem  with  many 
graphical  deeign  tools  is  that  one  can  put  a  bad  design  In  and  get  bad  code  out  (garbage  in, 
garbage  out).  On  many  representations,  it  would  be  wise  to  do  several  types  of  correctness 
checks  such  as: 

Paraaeeer  astching 
Xsdundency  checks 
gxCraneous  State  cheeks 
Design  Simuiatlon 
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Th«  g«n«r«tion  of  source  code  een  be  delayed  If  the  progreeaer  has  soaa  assurance  chat  his 
graphical  design  is  fundaaenCally  valid.  Once  the  coda  for  a  particular  representation  has  been 
generated,  the  prograaaer  will  tend  to  edit  the  coda  and  not  the  graphical  representation. 


(3)  Coding  Tools 

The  text  editor  continues  to  be  Che  single  noat  inf^rtant  software  design  Cool  available  to 
Che  progranaer.  This  la  because  prograaaers  will  tend  to  chose  the  cool  which  places  the  least 
Inhibitions  on  their  ability  to  design  and  code  software.  One  fundaaental  problea  with  object 

oriented  prograaaing  tools  is  that  they  often  constrain  the  r — q - to  a  few  standardized 

aethods  of  prograaaing.  This  often  results  in  the  prograaaer  discarding  the  tool  when  he  finds 
enough  operations  which  he  caonot  represent  with  it.  Furthermore,  if  the  prograaser  finds 
himself  switching  back  between  the  text  editor  and  another  cool  often  enough,  he  will  probably 
stick  Co  the  one  he  feels  most  comfortable  with  (moat  likely  the  text  editor)  in  order  to  reduce 
overhead.  Because  of  its  importance,  the  text  editor  is  one  area  where  significant 
productivity  gains  can  still  be  achieved;  soae  guidelines  to  this  end  are  outlined  in  the 
following  paragraphs. 

The  text  editor  should  support  all  standard  editor  functions.  The  text  editor  should 
support  the  insertion  and  deletion  of  characters,  words,  lines,  and  buffers.  Buffers  should  be 
available  to  copy  code  into  and  out  of;  this  is  essential  when  similar  code  is  used  in  different 
areas  of  the  program.  The  editor  should  also  have  the  ability  to  search  for  and  substitute 
strings.  Lastly,  the  editor  should  give  its  user  the  ability  to  move  quickly  to  any  part  of  the 
file.  Standard  editor  functions  should  be  Invoked  using  keystroke  sequences.  The  functions 
mentioned  here  are  fairly  basic. 

The  text  editor  should  allow  Che  user  to  edit  two  or  more  files  at  one  time.  Since  many 
programs  extend  over  several  source  files  (with  each  source  file  being  the  equivalent  of  a 
package),  this  is  a  desirable  feature  Co  have.  It  may  be  desirable  to  implement  this  by 
partitioning  the  screen  into  multiple  editor  buffers. 

The  text  editor's  functionality  should  shorten  the  ediC-coaq>ile*llnk-run>debug  cycle. 
There  are  many  ways  to  achieve  this.  One  way  is  to  evoke  coaponenta  of  the  prograaaing 
environment  such  as  Che  compiler  and  the  interpreter  can  be  directly  from  the  editor.  If 
semantic  and  logic  errors  are  caught  in  the  source  file,  modifications  to  the  source  code  can  be 
made  and  teated  without  having  to  contlnuoualy  switch  modes.  In  addition,  If  the  editor  is 
syntax  aenaltive,  syntax  errors  be  can  caught  and  corrected  aa  Che  code  la  being  entered.  This 
will  reduce  the  number  of  *stupld*  mlatakes  commonly  made  by  prograaaers. 

(4)  CooqpilaCion  System 

Although  the  c(»pilaclon  system  is  the  most  important  aspact  of  the  prograaaing 
environaenc,  the  functions  performed  by  the  compiler  ere  being  increasingly  shared  with  ocher 
components  of  the  environment.  For  example,  the  lAda  editor  in  Che  lAV  can  perform  Incremental 
syntax  and  semantic  analysis;  these  are  functions  commonly  reserved  for  the  compiler.  The 
performance  of  a  compilation  system  is  the  factor  which  will  make  or  break  the  productivity  of 
any  programer.  A  slow  compiler  will  offset  the  advantage  of  any  software  engineering  tool,  no 
matter  how  useful.  In  light  of  this,  It  is  Important  that  guidelines  for  compiler  quality  be 
referenced  in  this  report.  The  following  performance  guidelines  for  a  compilation  system  are 
suggested; 


(a)  The  compiler  shall  produce  an  object  code  program  that  requires  no  more  Chen  30% 
additional  target  computer  memory  space  over  an  equivalent  program  written  in  assembly  language. 
13] 


(b)  The  compiler  shall  produce  an  object  code  program  that  requires  no  owre  Chan  15% 
additional  execution  time  over  an  equivalent  program  written  in  assembly  language.  [3] 

(c)  The  compiler  shall  compile  a  syntactically  and  semantically  correct  Ada  program 
of  at  least  200  Ada  source  statements  at  a  rate  of  at  least  200  statements  per  minute  (elapsed 
tism),  for  each  1  NIPS  of  rated  processing  speed  of  the  specified  host  computer,  while  meeting 
the  above  object  code  requirements.  (3) 

(5)  Maintenance  Tools 

It  is  important  that  the  software  maintenance  team  have  access  to  the  same  tools  used  by 
the  developers.  The  use  of  object  oriented  programing  tools  will  cause  a  great  deal  of  design 
information  to  be  sledded  in  the  design  representation.  This  la  especially  true  If  a  PDL  or 
requiresMnta  database  is  constructed  relative  to  the  graphical  represantatlona  used  by  the  tool. 
A  switch  to  another  envlronsent  may  result  In  the  loss  of  critical  malntenanca  information, 
especially  If  the  object  oriented  representations  are  treated  as  part  of  the  software 
documentation.  This  Is  one  reason  why  more  e^hasls  should  be  placed  on  the  portability  of  the 
progreaming  environment.  A  programming  environment  which  is  relatively  portable  can  be  placed 
on  the  upgrades  or  replacement  to  e  particular  host  computer  (Indeed  this  may  need  to  be  done 
several  times  over  a  given  weapons  lifecycle).  AfVAL  la  currently  working  in-house  on  a  tool 
callad  APEX  (Avionics  Programming  Expert)  which  will  address  the  definition  of  a  common  software 
maintenance  environment  for  avionics  software. 
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IV.  Coneliuloii 

Therft  tif  trands  which  are  significantly  alcarlng  tha  way  softwara  la  developad; 

thaaa  Includa: 

••  rha  iacrMSing  cote  of  sofevtro. 

--  Tha  Increttlng  MVtilsbiliey  of  cheaper,  mart  powarfuJ  engineering  workscacions. 

Tha  rite  of  lenguege  end  operecing  ajratea  acenderdizeclon. 


Thaaa  tranda  ara  resulting  In  tha  davalopaant  of  prograanlng  anvlronnents  and  toola  which 
era  both  Bora  portable  and  potentially  Bora  productive  than  their  pradaceaaora .  Unfortunately, 
this  new  programing  technology  is  still  Imatura  in  nany  waya  and  potential  users  oust  be  given 
guidalinaa  to  Judge  tha  overall  affectivanaas  of  thaaa  ayatasa.  Thaaa  guidelines  can  also  help 
alert  either  the  tool  designer  or  user  to  potential  difficulties  before  comittlng  to  a 
potentially  costly  softwdra  developaant  scheBS.  Because  of  the  Increasing  cost  of  software 
davelopBent,  the  ioportanca  of  evaluating  programing  environBents  is  becoming  sore  widely 
recognised.  This  paper  presents  a  number  of  guidelines  and  considerations  which  can  aid  either 
the  tool  designer  or  applications  prograaaer  in  judging  a  particular  programing  environment. 
These  guidelines  are  based  or.  lessons  learned  from  a  prototype  software  developBent  environment 
(tha  Interactive  Ada  Workstation).  By  accomplishing  this,  this  paper  also  gives  Insight  into 
the  direction  that  software  development  Is  taking. 
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ABSTRACT 

An  environment  for  capturing  requirements  and  incrementally  developing  a  formal 
specification  is  introduced.  This  environment/  called  RISE/  is  based  upon 
Place/Transition  (P/T)  Nets,  P/T  nets  are  extended  within  RISE  to  support 
timing  requirements  and  hierarchical  decomposition  as  well  as  providing  other 
extensions  necessary  for  the  development  of  a  software  specifications.  The  main 
focus  of  this  effort  was  to  define  the  semantics  of  hierarchical  decomposition 
of  P/T  nets. 


INTRODUCTION 

In  order  to  build  successful  software  systans  it  is  essential  that  all 
requirements  be  captured  in  the  form  of  a  specification  and  validated  against 
user  intent.  This  information  includes  functional  decomposition/  data  flow 
descriptions/  control  flow  descriptions/  real-time  requirements/  and 
fail-safe/fail-soft  requirements.  Most  specification  systons  currently  in  use 
do  not  provide  the  expressibility  to  capture  all  these  requirements/  nor  do  they 
provide  an  adequate  means  for  validating  the  specification. 

In  [51  six  criteria  are  put  forward  for  the  evaluation  of  a  specification 
language/methodology.  The  criteria  are: 

a.  Formality  --  formal/  unambiguous/  mathematical  basis 

b.  Constructibility  —  build  specif ication  without  undue  difficulty 

(1)  initial  construction 

(2)  Captures  programmers*  concepts 

c.  Comprehensibility  —  readability,  size/  and  lucidity 

d.  Minimality  --  does  not  over  specify,  focuses  on  "what"  only 

e.  Wide  Range  of  Applicability 

f.  Extensibility  —  small  change  in  concept  results  in  small  change  in 
specification 

Current  specification  systems  address  these  criteria  to  varying  degrees,  often 
trading  off  strengths  in  some  areas  at  the  expense  of  others. 

Petri  nets,  because  of  their  formality  and  inherent  ability  to  hcmdle 
concurrency  and  synchronization,  can  be  used  as  a  specification  methodology,  but 
have  proven  inadequate  when  building  systems  of  realistic  size  and  complexity. 
In  recent  years,  worK  has  been  done  to  provide  hierarchical  decomposition  and  an 
adequate  representation  of  time.  Recent  worK  has  also  resulted  in  more 
expressive  Petri  nets  than  the  original  Condition/Event  and  Place/Transition 
nets  [31/  namely  relation  nets  [4]  and  Predicate/Transition  nets  [2].  In  total, 
this  work  has  enabled  a  teal  world  specification  methodology  based  on  Petri 
nets. 

RISE,  Requirements  and  Incremental  specification  Environment,  is  based  on  the 
previously  mentioned  work.  This  paper  will  describe  RISE  in  terms  of  its 
foundations  in  Petri  net  theory,  its  extensions  to  Petri  net  theory,  and  then 
describe  future  work  based  on  lessons  learned  during  this  effort. 


RISE  FUNCTIONAL  OVERVIEW 

RISE  breaks  the  specification  process  up  into  two  main  activities:  1) 
developing  and/or  evolving  the  specification  and  2)  validating  the 
specification,  at  any  stage  during  the  development,  against  user  intent.  RISE 
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provides  the  ability  to  specify,  both  graphically  and  textually.  the  system 
under  development  while  allowing  the  user  to  incrementally  develop  the 
specification.  RISE  provides  abstraction  mechanisms  which  allow  the  user  to 
elaborate  arbitrarily  the  specification,  putting  off  details  until  the  specifier 
is  ready  to  handle  them.  RISE  allows  for  the  specification  to  be  partially 
validated  at  any  point  during  the  developaent.  RISE  does  this  by  executing,  or 
more  accurately  animating,  its  specification  at  the  level  the  specification  is 
captured.  RISE  does  this  by  taking  advantage  of  the  net  semantics  which  allow  a 
net  to  be  animated  at  the  specification  level  without  generating  a  low  level 
implementation. 


PLACE/TRANSITION  NET  FOOHOATIONS  FOR  RISE 

This  section  will  characterize  place/transition  (P/T)  nets,  describe  extensions 
to  support  a  hierarchy  of  P/T  nets,  timing  requirements,  and  other  extensions 
necessary  for  specifying  software  systems. 

Definition  1:  A  P/T  net  is  described  as  a  6-tuple,  N  -  (S,  T;  F,  K,  H,  H)  in 
[3]  where: 


a.  (S,  T;  F)  is  a  finite  net,  the  elements  of  S  and  T  are  called  places  and 
transitions,  respectively.  F  defines  the  arcs  which  connect  S  outputs  to  T 
Inputs,  and  vice  versa; 

b.  K:S  — >  N,  gives  a  (possibly  unlimited)  capacity  for  each  place  (where  N 
is  an  Integer); 

c.  W:F  — >  N\{0),  attaches  a  weight  to  each  arc  of  the  net  (weight 

corresponds  to  the  number  of  tokens  which  must  travel  along  the  arc); 

d.  H:S  — >  N  is  the  initial  marking  representing  the  number  of  tokens  in 
place  a,  respecting  the  capacities  (i.e.,  H(s)  <•  K(s)) 

Definition  2:  Firing  rules  for  P/T  nets:  Under  a  given  marking  H(s)  a 

transition  tC  T  is  M-enabled  iff 

Vsft  :  M(s)  >-  W(s,t)  /N 

t’:  M(a)  <-  K(s)  -  W(t,s) 

where  * t  is  the  set  of  input  places  of  t  and  t*  is  the  set  of  output  places  of 
t. 

The  follower  marking  is  the  result  of  an  H-enabled  transition  firing.  When  it 
fires,  places  s£ * t  lose  W  (s,t)  tokens  and  places  s(  t*  gain  W  (t,s)  tokens. 
The  follower  marking  M*  is  described  by: 

f  H(s)  +  W(t,s)  iff  s^  t* 

M' (s)  =■  i  N(8)  -  W(B,t)  iff  se*t 

(.  otherwise  H(8) 

If  more  than  one  transition  is  simultaneously  enabled,  only  one  will  be 
arbitrarily  selected  and  fired. 

Graphically,  places  are  represented  as  circles,  treuisitions  as  rectangles, 
tokens  as  dots,  ai:d  arcs  as  lines  connecting  S  to  T  (and  T  to  s) .  When 
transitions  fire,  tokens  move  through  the  net  along  arcs.  This  shows  the 
dynamic  behavior  of  the  specified  system. 


EXTENSIONS  TO  PLACE/TRANSITION  NETS 

P/T  nets  as  described  thus  far  have  clear,  simple  semantics  with  regard  to 
capturing  comurrency  and  synchronization,  but  have  been  inadequate  when  dealing 
with  systems  of  realistic  size  and  complexity.  In  particular,  P/T  nets  do  not 
provide  a  mechanism  for  hierarchical  decosposition  nor  a  mechanism  to  specify 
timing  requirements  (other  than  relative  time  relations,  i.e.,  immediately 
before/after  and  arbitrary  ordering). 

RISE  incorporates  hierarchical  decomposition  and  timed  P/T  nets  similar  to  [1]. 
In  sumioary,  [II  used  places  to  model  system  activities.  This  allowed 
transitions  to  retain  their  original  convention  of  representing  instantaneous 
events,  while  places  on  the  other  hand,  represent  activities  which  ate  active 
when  a  token  is  present  within  the  place.  An  activity,  which  takes  a  finite 
amount  of  time,  has  a  corresponding  time  argument  associated  with  it.  Therefore 
in  a  P/T  net  an  activity  is  represented  by  a  single  place  and  has  an  associated 
time  argument.  Each  place  may  be  decomposed  into  a  subnet  which  further 


18-3 


•laboiatas  the  details  of  the  associated  activity  and,  in  turn,  each  place  of 
the  subnet  aay  be  further  decoi^osed.  This  allows  for  arbitrary  deconposition 
of  a  specified  system. 

Time 

RISE  differs  from  [1]  by  using  two  tine  arguments  (tain  and  taax)  for  each  place 
rather  than  a  single  time  argument.  This  allows  the  specifier  to  specify  a 
variety  of  timing  requirements  on  a  place  (e.g.,  a  maximum  time,  a  minimum  time, 
a  range,  or  an  exact  time) ,  rather  than  a  single  exact  tine.  Time  arguments  are 
used  during  net  animation  to  check  dynamically  for  timing  requirements 
violations.  Currently,  static  evaluation  is  not  implemented. 

During  animation,  time  in  RISE  is  updated  like  simulation  systems  with  event 
clocks.  When  the  next  event  occurs  it  updates  the  clock  by  the  amount  of  time 
the  activity  took.  This  results  in  contiguous,  non-regular  time  intervals  which 
support  arbitrary  time  fidelity.  Within  RISE  each  subnet  has  an  evaluation  mode 
argument  used  to  specify  best  case  or  worst  case  timing  (i.e..  Did  the  activity 
take  tmin  or  tmax  time?).  If  the  amount  of  time  a  token  spends  in  the  subnet 
does  not  satisfy  the  timing  requirements  of  the  parent  place,  RISE  informs  the 
user. 

Hierarchical  Decomposition 

RISE  supports  two  types  of  decomposition:  open  system  decomposition  (OSD),  and 
closed  system  decomposition  (CSD).  Deconposition  may  be  done  on  any  place.  The 
type  of  decomposition  of  the  place  depends  on  the  type  of  elaboration  the 
specifier  desires.  OSD  is  meant  to  provide  lower  level  details  of  the  parent 
place  which  ace  fully  consistent  with  the  parent  place.  CSD  is  also  meant  to 
provide  lower  level  details  of  the  parent  place,  but  ace  not  required  to  be 
fully  consistent  with  the  parent  place,  A  CSD  subnet  is  meant  for  refinement  of 
the  abstraction  represented  by  the  parent.  A  CSD  subnet  will  remove 
generalizations  assumed  in  the  parent  place  and  deal  with  exceptional  cases  not 
previously  incorporated  in  the  specification. 

In  both  OSO  and  CSD,  when  a  token  enters  a  place  with  an  associated  subnet,  it 
Indicates  that  the  net  is  in  a  certain  state.  The  difference  between  the  two 
types  of  subnets  is  best  illustrated  by  how  they  act  in  relation  to  their  parent 
place.  A  OSD  sujaiet  operates  within  the  environment  provided  by  its  parent 
place.  A  CSD  subnet  replaces  the  parent  place  and  provides  a  new,  generally 
more  specific  environment. 

Open  System  Decomposition  —  Operationally,  when  a  token  enters  a  place  with  an 
associated  OSO  subnet,  it  is  passed  down  the  hierarchy  to  the  subnet  via  an 
input  transition.  The  token  then  passes  through  the  subnet  and  is  passed  up  the 
hierarchy  via  an  output  transition.  The  token  being  passed  to  and  from  an  OSD 
subnet  is  similar  to  a  function  call  with  tokens  analogous  to  arguments.  The 
subnet  simply  provides  a  more  detailed  accounting  of  what  the  parent  place 
represents. 

OSD  incorporates  concepts  from  [1]  for  a  precise  methodology  for  decomposition. 
In  [II  there  ate  nine  hierarchical  net  transformations,  each  of  which  may  be 
applied  iteratively  to  a  simple  place  (i.e.,  a  place  with  one  input  and  one 
output)  resulting  in  a  more  complex  net.  These  transformations  are:  sequence 
of  simple  places,  asynchronous  parallel  paths,  synchronized  parallel  paths, 
predetermined  two-way  decision,  data-dependent  n-way  decisions,  predetermined 
two-way  alternation,  data-dependent  n-way  alternation,  independent  cycle,  and 
bounded  iteration.  In  RISE,  a  subnet  must  be  provably  derived  via  the 
decomposition  rules  previously  listed,  though  for  ease  of  use  during 
specification  development,  this  constraint  is  not  constantly  enforced,  but 
rather  is  applied  when  directed  by  the  user. 

Closed  Systeiii  Decomposition  —  Operationally,  when  a  token  enters  a  place  with 
an  associated  CSD  subnet,  the  place,  with  the  token  present,  represents  that  the 
system  is  in  a  specific  state.  Information  about  the  system  must  be  derived 
from  the  subnet,  rather  than  from  the  parent  place.  CSD  subnets  are  closed 
Petri  nets  with  initial  markings.  When  a  token  is  present  in  the  parent  place 
the  subnet  is  activated.  It  will  remain  active  until  the  token  leaves  the 
parent  place.  When  this  will  happen  is  dictated  by  the  net  of  which  the  parent 
place  is  a  member. 

With  respect  to  the  initial  marking  of  the  subnet,  there  are  two  types.  In  the 
first  tyM  of  initial  marking,  tokens  are  always  in  the  same  place  each  time  the 
subnet  is  activated.  In  the  second  type  of  initial  marking,  tokens  are  in  the 
places  they  were  last  at  when  the  subnet  was  last  activated.  which  type  of 
initial  marking  is  associated  with  the  subnet  is  dependent  on  what  the  specifier 
states.  • 
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In  a  RISE  specification,  all  nets  ate  not  necessarily  related  to  each  other  in 
soae  hierarchical  nanner.  Rather,  the  specification  of  aost  real  systeas  would 
typically  consist  of  aultiple,  essentially  independent  (i.e.  interaction  via 
shared  resources  only),  siaultaneous  nets.  RISE  allows  the  specifier  to 
describe  such  nets  and  anlaate  these  nets  to  see  how  they  interact  on  shared 
resources. 

Another  deviation  froa  [1|,  and  applicable  for  both  OSD  and  CEO  subnets  is  the 
preservation  of  all  levels  of  the  hierarchy.  In  [11,  decoaposition  is  strictly 
one  way.  That  is,  when  a  place  is  further  refined  (decoi^osed) ,  it  is  analyzed 
and  anlaated  only  at  this  lower  level.  In  RISE,  all  levels  of  the  hierarchy  are 
preserved,  thus  allowing  the  user  to  analyze  the  P/T  net  at  whichever  level  of 
abstraction  he/she  wishes.  (See  EXAMPLE  for  aore  detail.) 

Coepound  Places 

In  Petri  nets,  there  is  sn  iiplicit  queueing  of  tokens  in  places.  As  a  result 
there  is  some  anbiguity  with  respect  to  what  activities  are  being  modeled.  For 
ezaaple,  consider  the  net  below: 

transition  tl  can  not  fire  because  k  of  p2  would  be  violated. 


lot 


Pig.  1 

What  does  the  token  in  pi  aean?  Is  the  activity  associated  with  pi  still  in 
progress  or  has  it  been  completed  and  is  simply  waiting  for  tl  to  fire.  If 
there  are  any  shared  resources  used  by  pi,  when  are  they  released?  This  queuing 
is  necessary,  but  must  be  explicitly  handled,  so  that  a  user  specifies  where  and 
when  queuing  should  occur.  In  RISE,  this  is  handled  by  defining  a  RISE  place  as 
a  compound  place  consisting  of  a  sequence  of  three  places:  input  queue  (IQ), 
active  queue  (AQ) ,  and  output  queue  ((X)).  The  IQ  is  where  tokens  enter  the  RISE 
place  and  wait  until  they  can  enter  the  AQ.  Tokens  move  frm  IQ  to  AQ  when 
able.  Tokens  in  the  AQ  indicate  that  the  activity  is  actually  taking  place. 
Whan  the  activity  is  completed,  tokens  move  to  the  OQ.  Only  tokens  in  the  OQ 
can  enable  output  transitions. 

TVo  clarifications  with  respect  to  the  time  representation  are  necessary  in 
light  of  compout:d  places.  Pitst,  the  two  time  arguments  refer  to  the  time  the 
tokens  are  in  the  AQ.  And  second,  in  addition  to  transition  firing  being 
instantaneous,  so  is  the  movement  of  tokens  between  queues  within  a  compound 
place. 


Fig.  2 

Within  RISE,  all  places  are  cospound.  As  a  result  a  single  R  bound  (capacity) 
is  no  longer  sufficient.  Within  RISE  each  place  has  two  K  t>ounds:  K(place), 
capacity  of  the  entire  place  —  sum  of  IQ,  AQ,  and  OQr  and  K(aq),  capacity  of 
AQ.  These  caiMcities  put  additional  constraints  on  when  tokens  can  move  between 
queues,  as  well  as,  when  a  transition  can  fire. 

With  respect  to  hierarchical  decomposition,  subnets  are  associated  with  the  AO, 
rather  than  with  the  place  as  a  whole.  This  works  well  for  OSD  subnets,  but 
requires  a  modification  of  compound  places  in  order  to  support  CSD  subnets. 
Places  with  CSD  subnets  contain  only  an  IQ  and  an  AQ.  Once  a  token  enters  the 
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AQ  it  is  eligible  to  enable  an  output  transition  and  its  activity  will  continue 
until  the  output  transition  fires  (in  contrast  with  standard  compound  places 
which  complete  their  activity#  move  their  token  from  AQ  to  OQ,  and  then  enable 
output  transitions  frosi  the  OQ  only). 


example 

In  this  section#  a  portion  of  an  air  traffic  control  system  (ATCS)  will  be 
described.  The  purpose  is  to  illustrate  some  of  rise's  features. 

We  begin  the  specification  by  picking  certain  functions  we  wish  to  specify: 
tracking  aircraft#  running  a  monitor#  and  eaecuting  a  hand  off.  Tracking 
aircraft  (fig.  3)  and  running  a  monitor  (fig.  5)  are  two  continuous  functions 
which  must  be  performed  as  long  as  the  ATCS  is  in  use.  Executing  a  hand  off 
(fig.  4)  is  initiated  by  the  air  traffic  controller  whenever  an  aircraft  leaves 
the  air  space  of  the  controller  and  moves  into  the  air  space  of  another 
controller.  At  the  top  level  these  functions  are  essentially  independent 
operations#  hence  at  this  level  we  have  three  separate  nets.  As  we  elaborate 
the  specification  and  move  down  the  hierarchy  the  interaction  between  these 
functions  are  specified. 


Figure  3  is  a  net  of  how  the  ATCS  handles  radar  track  data.  Each  place 
represents  an  activity  necessary  to  handle  radar  track  data.  For  the  purposes 
this  paper#  the  annotations  within  each  place  are  sufficiently  descriptive. 
In  order  for  RISE  to  be  used  for  realistic  specifications#  the  annotations  need 
^  formalised.  As  an  example#  places  in  both  figure  3  and  figure  5  could 
perform  operation  on  the  same  elements  of  the  database  (i.e.#  the  acquisition 
list  and  the  coast  list).  This  is  not  clear  fr<»i  the  current  specification. 
Part  of  this  could  be  addressed  within  RISE  by  refining  figure  5  down  to  include 
what  makes  up  the  database  (e.g.#  explicitly  state  that  the  database  contains 
the  acquisition  list  and  the  coast  list).  This  is  clearer#  but  still  ambiguous. 
This  will  be  addressed  in  the  future  work  section. 


Currently  in  RISE#  each  place  has  seven  RUNhtONrrons 

attributes:  tmin#  tmax#  tactuali  number  of  tokens 
in  IQ#  AQ#  and  OQ;  and  a  pointer  to  the  associated 
subnet  if  it  exists.  To  prevent  cluttering  of 
diagrams  these  attributes  have  generally  not  been 
provided  in  the  example  unless  absolutely 

necessary.  Ttw.tw 


Fig.  5 

Figure  4  describes  the  execution  of  a  hand  off  of  an  aircraft  from  one 
controller  to  an  other.  Places  "Initiate  Hand  Off*  and  "Delete  Entry*  have 
associated  OSD  subnets#  figures  6  and  7  respectively.  Place#  "Await  Control 
Acquire*#  is  fully  specified  and  will  not  be  elaborated  any  further.  Places 
labelled  "Input:  ..  ■  are  types  of  places  which  facilitate  user  interaction 
within  the  net. 


MrrUTE  HAND  OFF 
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OafTE  ENTRY 
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Pig.  6  Pig.  7 

Pigur*  5  ia  the  top  level  specification  of  the  run  monitor  function.  At  this 
level  the  only  requirement  we  are  specifying  is  that  changes  to  the  database  be 
reflected  on  the  screen  within  2  seconds. 

RISE  provides  the  ability  to  execute  the  specification  (animate  the  Petri  net) 
at  any  level  of  detail.  The  user  can  select  what  level  of  detail  or  what 
portion  of  the  specification  is  to  be  executed.  This  is  accomplished  by  the 
user  ’activating*  each  subnet  before  execution  begins.  Once  desired  subnets  are 
activated  only  those  subnets  will  be  used  during  execution.  This  facility  can 
be  used  to  present  views  of  the  system  appropriate  for  the  viewer.  Management 
and  top  level  system  designers  might  only  be  presented  the  top  few  levels  of 
detail.  Domain  experts  might  only  see  the  portion  of  the  specification  relevant 
to  their  specific  component  while  system  integrators  might  see  the  entire 
specification  or  just  critical  components. 


CORREMT  STATUS 

Everything  described  thus  far  is  fully  inplemented.  RISE  is  built  in  KEE  3.0 
running  on  a  Symbolics.  The  thrust  of  this  effort  has  been  on  how  to  build  and 
validate  realistic  formal  specifications.  The  need  for  a  graphical  presentation 
was  evident.  Also  necessary  were  mechanisms  to  support  multiple  levels  of 
abstraction  and  incremental  development,  both  of  which  are  necessary  for  large 
specifications.  It  was  felt  that  Petri  nets  had  the  necessary  formality  and 
simplicity  to  be  a  good  graphical  presentation.  One  of  the  biggest  problems  was 
to  define  the  semantics  of  the  hierarchical  decoxiposition  of  places  such  that 
they  would  support  multiple  levels  of  abstraction  and  incremental  development, 
hence  the  two  types  of  decomposition!  Open  System  Decosposition  and  Closed 
System  Decomposition.  At  this  point  I  believe  there  are  other  types  of 
decoapositions  which  would  provide  cleaner  building  blocts.  The  first  step  in 
this  direction  is  to  treat  the  type  of  decomposition,  open  systems  verses  closed 
systems,  separately  from  whether  or  not  the  decomposition  is  an  extension  (i.e., 
more  information  which  is  consistent  with  previous  information)  verses  a 
refinement  (i.e.,  more  information  which  may  not  be  consistent  and  thus 
invalidate  previous  information).  These  issues  are  orthogonal  to  each  other  and 
should  be  dealt  with  separately. 


FUTURE  MORE 

Future  work  will  focus  in  two  areas.  The  first  area  will  be  elevating  the 
underlying  Petri  nets  of  RISE  from  Place/Transition  nets  to  Predicate/Transition 
nets.  This  will  allow  constraints  to  be  expressed  as  predicates  Inside 
transitions,  while  also  allowing  information  to  be  carried  inside  tokens. 
Already  completed  in  support  of  this  work  is  a  token  description  language  (based 
on  abstract  data  types)  and  the  beginnings  of  a  constraint/predicate  language 
(i>ss*d  on  first  order  logic  and  set-theoretic  data  types)  The  second  area  of 
focus  will  be  on  the  interaction  of  refinement  constraints  and  extension 
constraints  during  place  decrnsposition.  This  work  will  Identify  the  mechanisms 
necessary  for  elaboration  and  refinement  of  Petri  nets  through  hierarchical 
decomposition.  This  work  will  draw  heavily  on  work  done  by  University  of 
southern  Callfornla/lnformation  Sciences  Institute  on  Incremental  development  of 
GIST  specifications  (f). 
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DISCUSSION 

W.Mansel,Ge 

Petri-Networki  are  an  excellent  method  in  modelling  process  control  in  real-time  systems.  However,  they  have  the 
tendency  to  become  complicated  and  difficult  to  handle  and  therefore  are  not  easily  accepted  by  software  engineers. 
Can  you  please  comment  on  the  benefits  of  the  RISE  approach  compared  to  the  simpler  methods  of  structured  analysis 
with  data  flow  and  control  flow  control? 

Author’s  Reply 

The  advantage  of  RISE  over  techniques  like  stiuctured  analysis  lies  with  the  greater  degree  of  formality  found  in  RISE 
Petri-Nets.  With  regard  to  the  complexity  of  large  Petri-Nets,  RISE  provides  the  necessary  abstruction  mechanisms  to 
reduce  this  complexity. 
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Summary 

Based  on  a  generic  system  developmem  concept  a  test  strategy  has  been  established  within  MBB  Military  Aircraft 
and  Helicopler  Division.  In  order  to  support  this  strategy  a  tool  set  has  been  developed  which  is  being  used  for  all 
projects  and  throughout  aH  development  phases.  Due  to  Its  free  configurability  it  can  easily  be  adapted  to  production 
line  applications  as  welf  as  to  other  purposes. 


1.  Introduction 

Over  the  last  decade  we  have  witnessed  enhancing  requirements  of  flying  weapon  systems  and  subsequently  bieir 
growing  complexity.  However,  this  evolution  is  not  tuHy  desc^bed  by  the  number  of  system  components  and  their  internal 
structures.  With  the  introduction  of  bus  systems  Into  military  aircraft  all  components  merge  to  form  just  one  complete 
system  which  is  cortirolled  by  a  continuously  growing  system  software.  The  traditional  simple  separation  of  the  system  into 
software  and  hardware  does  not  seem  to  be  meaningful  any  more.Today  the  budgetary  contribution  of  avionic  systems  to 
the  total  cost  of  a  military  aircraft  is  substantial.  Hundreds  of  system  engineers  and  software  engineers  are  involved  in  fhe 
development  of  a  flying  weapon  system.  Besides  the  technical  challenge  this  represents  a  problem  of  organization 
which  we  have  solved  by  Introducing  a  rigid  methodology  for  system  engineering. 

Based  on  a  generic  system  development  concept  (see  paper  no.  9  of  this  conference  for  details)  a  test  strategy 
has  been  established  within  the  MBB  Military  Aircraft  and  Helicopter  Division  that  provides  the  appropriate  facilities  to 
support  an  phases  of  a  system's  life  oycle.  The  focus  of  this  paper  is  the  description  of  these  facilities,  that  enable  the 
design,  development  test  and  Integration  of  complete  systems.  As  it  will  become  clear  later,  these  facilities  are  not 
meant  to  replace  the  usual  system  and  scftware  dev^opment  tools  (like  CORE/EPOS,  PRCMOD  etc.),  but  are  additional 
instruments. 


2.  The  MBB  Test  Strategy 

Figure  1  shows  a  simplified  picture  of  a  system  life  cycle.  At  all  development  and  integration  phases  we  provide 
facilities  that  support  systems  engineering.  We  wM  describe  these  facilities  and  their  relevance  to  the  Afferent  phases  in 
this  chapter  in  a  generalized  way  and  present  the  actual  realization  In  the  next  chapter. 


2.1  Tactic  Simulator 

In  the  very  early  development  phase  of  a  new  aircraft  fhe  tactical  requirements  have  to  be  worked  out.  Based  on 
general  mWtary  requirements  the  actual  performance  of  the  system  has  to  be  defined.  This  phase  is  supported  by  the  MBB 
-  UF  simulation  centre,  offering  various  high  fidelity  real  time  simulations.  Nearly  ak  characteristic  aircraft  system  parame¬ 
ters  (speed,  altitude,  wmg  sweep,  flap  setting,  etc.)  can  be  modeled  on  the  bases  of  approximately  70000  coefflclenis. 
(using  an  aircraft  model  In  6  degrees  of  freedom,  aerodynamical  rules  etc.)  and  control  laws  can  be  worked  out.  Thus 
the  performance  of  the  parameterized  aircraft  can  be  tested  under  realistic  conditions  (cockpit  with  v^  simulation  )  and 
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m  principle  two  simulators  can  be  linkecl  m  order  to  test  combat  performance.  In  this  phase  no  real  equipment  besides 
some  commercial  displays  and  controls  exist  and  the  complete  aircraft  is  simulated. 


Phases : 


Facilities : 


Tactical  Requirements 


I 


Figure  1  System  Life  Cycle 


2.2  System  Prototyping  Rig 

Once  the  tactical  requirements  are  defined  the  system  has  to  be  designed.  Experience  in  system  development 
has  shown  that  costs  for  error  correction  increase  exponentially  with  the  progress  of  system  development. 

Therefore  MBB  uses  the  concept  of  System  Prototyping  for  early  design  verttication  thereby  reducing  risks  and 
saving  costs.  System  Prototyping  means  the  experimental  technical  and  operational  assessment  of  system  perfonnance 
at  an  early  development  stage.  It  comprises  investigations  of  system  architectures  and  new  technologies  and  allows  to 
assess  critical  problems  and  ergonomic  aspects  not  only  theoretically  but  also  by  experiment.  The  System  Prototyping  Rig 
Is  a  major  tool  tor  a  disciplined  and  well  controlled  system  development  approach.  The  main  functions  of  this  rig  are  : 

*  System  Analysis 

*  Tool  Evaluation 

*  System  Test  Bed 

System  Analysis  means  experimental  test  and  verificatfon  of  new  system  architectures  to  support  the  system  design.  It 
Includes  the  early  verfllcatlon  and  demonstration  of  system  performance.  Tool  Evaluation  means  test  and  verification  of 
software  development  environments.  System  Test  Bed  means  the  experimental  tests  of  new  equipment  In  a  reaHstic  system 
environment  It  comprises  m  particular  the  pilot's  assessment  ol  man  /  machine  Interfaces  m  the  cockpit  e.g.  of  display 
formats,  cockpit  modktg,  arrangement  of  cftspiays  and  controls. 
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2.3  Integration  Rigs 

Once  the  aircraft  system  is  defined  the  equipment  has  to  be  deveioped  and  integrated.  There  is  no  canonical 
rule  how  to  group  equipment  to  subsystems  and  how  many  Intermediate  test  stages  are  needed  In  going  from  the  single 
module  test  to  the  final  system  integrafton.  The  guideline  Is  to  minimize  the  data  traffic  and  the  number  of  signal  fines 
between  the  different  groups,  leading  naturally  to  meaningful  subsystems.  Depending  on  the  amount  of  work  that  has  to  be 
done  in  parallel  the  number  of  subsequent  rigs  has  to  be  determined. 

The  test  scenario  that  has  proven  to  be  efficient  is  described  In  Figure  2.  Tests  are  performed  at  different  levels  of 
complexity,  thus  providing  the  necessary  support  at  each  stage  to  allow  for  parallel  testing  of  subsystems  and  avoiding 
an  overload  at  the  final  Integration  rig: 

-  Software  Benches  /  Hardware  Benches 

-  Subsystem  /  System  Software  Integration  Rigs 

-  System  Integration  Rigs 


Software  /  Hardware 

Subsystem  / 
System  -  Software 

System 

Bench 

integration  Rig 

Integration  Rig 

Figure  2  Stages  of  Testing 


The  test  objects  of  the  software  benches  and  hardware  benches  are  usually  one  piece  of  equipment,  e.g.  a  dedicatad 
computer  or  a  single  equipment.  The  benches  are  equipped  with  the  basic  corresponding  displays  and  controls  and 
facilities  for  example  for  loading  the  software  Into  the  target  computer.  Test  objects  of  the  Subsystem/System-Software 
Integration  Rigs  are  the  Interplay  of  all  the  freely  programmable  on  aircraft  computers  or  subsystem  equipment.  Again,  the 
peripheral  aircraft  hardware  Is  limited  to  the  basic  displays  and  controls.The  full  system  Integration  rig  comprises  ali 
functional  aircraft  equipment  with  as  much  as  possible  of  the  original  sensors  In  Ihe  loop  and  an  almost  fully  equipped 
cockpit.  This  Is  the  place  where  a  test  engineer  can  freely  create  his  test  scenario  by  conllgunng  the  system  elements 
according  to  Ms  demands. 
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2.4  Training  Simulators 

Derived  from  existing  development  and  integration  ladiities  MBS  has  provided  several  rigs  for  the  in-service  phase 
of  a  weapon  system.For  example  a  software  maintenance  facility  for  the  mission  relevant  software  maintenance  or  an 
avionic  system  trainer  lor  the  training  of  maintenance  personnel. 


2.5  The  General  fVg  Concept 

The  general  technical  concept  for  the  benches  and  rigs  Is  such  that  aU  relevant  signals  of  a  test  object  are 
accessible  via  patch  panels  to  simulation,  stimulation  and  measurement  equipment.  The  entire  signal  world  of  the  test 
object  Is  then  accessible  to  interfacing  equ^ent  and  a  range  of  computer  supported  Intelligence.  The  test  engineer  Is 
supported  by  a  user  Interface  that  has  Inlormabon  about  the  details  of  the  test  object  (like  physical  dimensions)  through 
a  'test  object  description  file'. 


2.6  Gonoral  Requlremonts  to  a  Teat  System 

On  the  one  hand  It  is  desirable  that  a  test  system  is  freely  configurable  according  to  the  particular  test 
requirements.  Depending  on  the  depth  of  the  test  different  levels  of  sophistication  are  required  lor  the  equipment  simula¬ 
tion.  The  amount  of  data  that  needs  to  be  recorded  and  analyzed  varies  substantially.  The  required  degree  of  test 
automation  varies,  depending  on  the  repehtion  rate  with  which  the  test  is  performed  resulting  In  a  broad  spectrum  of 
realtime  performance  requirements  to  the  test  system. 

On  the  other  hand  the  main  operations  of  the  simulation,  stimulation  and  measurement  equipmem  are  essentially 
Identical  throughout  the  different  phases  and  programmes. 

ft  should  be  evident  to  ask  for  a  homogeneous  family  of  test  systems  which  can  easily  be  adapted  to  the 
different  test  stages  and  tasks.  The  commercial  market  didn’t  solve  our  problem. 


3.  Th«  Tool  Sot  for  Software  and  Syatem  Integration 

In  order  to  provide  the  appropriate  test  systems  tor  each  application  MBS  has  developed  a  tod  set  from  which  a 
broad  spectrum  of  test  systems  can  be  configured.  This  approach  combines  the  advantages  of  dedicated  single  systems 
with  the  advantages  of  a  big  system  that  automaticaily  guarantees  comnwnality.  Thus  one  saves  costs  by  avoiding 
parallel  development,  training,  education  and  maintenance  of  different  test  tools  and  still  has  all  the  required  flexibility. 

The  name  of  this  tool  set,  AIDASS,  reflects  its  main  functions:  Advanced  Integrated  Data  Acquisition  and  Stimulation 
System.  It  consists  of  three  main  components  as  shown  in  Figure  3. 

-  Mum  Signal  Interface  Crate  (MUSIC). 

-  real  time  test  computer 

-  user  Interface  with  test  object  description 


3.1  Multi  Signal  Intarface  Crate  (MUSIC} 

The  coupling  of  all  signals  between  the  rig  and  the  test  computer  is  done  via  a  standard  interface  device.  It 
consists  of  a  VME  crate  equipped  with  a  CPU-board  for  preprocessing  of  signal  information  and  VME  interlace  boards  lor 
different  signal  types  (e.g.  analogues,  discretes,  synchros,  MB.  STD  1563  B). 


3.2  Real  Time  Teat  Computer 

Depending  on  the  actual  test  requirements  the  data  processing  capabRity  has  tc  be  defined.  The  high  performance 
end  of  the  real  time  hardware  spectrum  Is  a  muMprocessor  computer  which  can  be  equipped  with  up  to  six  paralel 
processing  unils.  The  test  software  Is  designed  such  lhat  subsets  can  be  created  for  lower  real  time  requirements  on  less 
powerful  computers,  such  as  personal  computers. 
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3.3  User  Interface 

m  cotnmefoially  available  test  tools,  e.g.  Milbus  testers,  a  detailed  knowledge  about  the  internal  signal  representa¬ 
tion  (bft  patterns)  of  the  test  object  is  required  for  the  user  to  property  operate  these  tools.  For  integration  purposes 
however  the  main  focus  of  the  test  engineer  is  on  the  physical  parameters  and  their  logical  interplay  in  the  system.We 
have  therefore  developed  an  intelligent  user  Interface  that  supports  the  test  engineer  by  providing  the  detailed  knowledge 
about  the  test  object  via  a  general  test  object  description  file. 


Personal  Computer  Work  Station 


Rgure  3.  AIDASS  Product  Range 


3.4  Present  Status  at  MBS 

At  present  we  have  developed  both  ends  of  the  product  range,  the  PC  version  and  the  fun  version  implemented  on 
a  CCC  3280  MPS.  As  we  have  placed  emphasis  on  software  portability  already  In  ihe  design  phase  the  Implementation  of 
AlOASS  on  a  smaller  computer  can  be  done  with  relatively  little  effort. 


4.  Further  Applications  of  the  Test  Tool  Set 

The  concept  for  the  test  system  AlOASS  was  primarily  driven  by  the  requirements  for  the  development  and 
integration  of  airaatl  systems.  Its  application  has  been  extended  to  flight  test  support  and  to  the  M6B  production  Hne. 
Presently  we  discuss  with  our  partners  In  intemalional  programs  lo  use  this  test  concept  in  common  to  assure  compatibility 
and  exchangeability  of  development  results. 

Due  to  the  fact  that  the  AlOASS  concept  can  be  easily  adapted  to  different  test  objects  through  a  test  object 
description  file  which  does  not  affect  the  test  software  Itself,  ACASS  Is  not  Hmlted  to  the  field  of  military  aircraft  develop¬ 
ment,  but  can  be  appNed  to  other  Helds  of  military  and  civil  development  projects. 
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DISCUSSION 

M-Muanler,  Franc* 

Using  your  AlOASS  system,  are  you  able  to  'Replay'  a  test  in  its  entirsty  (Regression  Testing)  or  partially  (i.e.  till  the 
point  where  an  anoma^  was  detected)  7 

Author’s  Reply 

Yes,  both  can  be  done.  Actually,  in  the  hill  AlOASS  contiguraiion  which  i  showed,  this  can  be  done  in  parallel  to  real 
time  operation  and  test  preparation. 

E-SevtUa,  Spain 

How  does  the  real  avionics  equipment  fit  into  ttie  AOASS  scheme?  Are  the  discrete  signals  going  from  one  avionic 
box  to  another  Interrupted  for  stimulating  and  recording  purposes  7 

Author's  Reply 

Not  necessarily.  For  recording  purposes  the  Ink  is  not  interrupted  but  the  signal  Is  split  between  the  test  computer 
and  the  destination  box.  If  equipment  is  slnuiated  by  the  test  computer  we  have  two  options,  if  the  equipment  can  be 
deactivated  electronically  then  the  Ink  can  be  kept  alive,  otherwise  the  link  has  to  be  cut  and  the  simulated  equip¬ 
ment  is  disconnected.  This  can  be  easily  done  on  our  patch  panels. 

C.Berggren,  U.S.A. 

Does  your  lest  computer  communicale  with  the  MUSIC  box  via  Ethernet  7 


Author’s  Reply 

No.  They  are  connected  by  a  VME-Unk. 
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"TOOLS  FOR  DEVELOPING  RBU.-T1HE  EMBEDDED  SYSTEMS  XN  EDA 
-  NEEDS «  PORTRBXLITY  AMD  EFFICIENCY" 

Elisabeth  Broe  Christensen 
Project  Manager 
DDC  International  A/S 
Lundtoftevej  1C 
OK-2800  Lyngby  (Copenhagen) 

Oenaark 


Suanary  ' 

Ada  offers  sofae  facilities,  which  were  not  part  of  older  languages,  if  you 
want  to  take  advantage  of  Ada  for  your  real-time  embedded  applications,  your 
development  tools  must  support  these  facilites,  and  do  it  in  an  efficient 
manner.  The  paper  presents  the  experiences  from  a  tool  project,  the  DDC-I 
symbolic  debugger  project,  which  has  as  its  goal  to  provide  a  tool  which  can 
fulfil  the  demands  of  real-time  embedded  applications  in  Ada. 


Introduction 

The  development  of  Ada  was  motivated  by  the  problems  of  embedded  real-time 
systems,  like  Avionics.  Ada  therefore  -  as  an  Integral  part  of  the  language  - 
offers  a  series  of  facilities  which  were  not  offered  by  the  classical 
languages  like  Pascal  and  FORTRAN,  such  as  parallel  tasking,  exception 
handling,  representation  specifications  and  inline-expansion.  Furthermore, 
the  language  was  standardized.  In  order  to  facilitate  reuse  and  portability. 

If  you  want  to  take  advantage  of  Ada,  development  tools  supporting  all 
aspects  of  the  language  are  needed.  Furthermore,  if  you  are  developing 
embedded  real-time  applications,  target  program  efficiency  In  terms  of 
execution  speed  and  storage  requirements  is  important.  To  make  such  tools 
available  to  as  many  developers  as  possible  at  a  minimum  cost,  the  tools 
should  be  easily  portable  between  different  host  computers,  target  computers 
and  operating  systems. 

DDC  International  A/S  (DDC-l)  is  a  Danish  company  dedicated  to  providing 
efficient  and  advanced  tools  for  Ada  program  development.  Among  other  things, 
we  are  known  for  efficient  cross-compilers  and  run-time  systems.  In  such 
cross-environments  you  are  both  allowed  to  take  advantage  of  the  facilities 
of  a  general  host  computer  for  the  program  development,  and  to  execute  the 
target  program  in  its  natural  surroundings. 

However,  in  order  to  take  full  advantage  of  the  cross- environment,  you  need 
an  important  tool  in  addition  to  the  cross-compiler:  A  symbolic  Ada  cross¬ 
debugger.  DDC-I  therefore  decided  to  expand  ita  portable  Ada  compiler  system 
to  Include  a  symbolic  debugger  as  well.  This  debugger  should 

-  support  the  features  of  Ada  properly 

-  be  useful  for  debugging  of  embedded  real-time  applications 

-  be  easily  portable 

In  the  following  it  will  be  described  how  we  have  achieved  these  goals  In  the 
DDC-I  symbolic  debugger  project,  with  examples  of  the  problems  we  have  found 
and  the  solutions  we  have  chosen. 


Proper  Support  of  Ada  Features 

As  mentioned  above  Ada  offers,  as  an  integral  part  of  the  language,  some 
facilities,  which  were  not  offered  hy  the  classical  languages  like  Pascal  or 
FORTRAN.  In  order  to  allow  you  to  take  full  advantage  of  Ada,  your 
development  tools  -  In  this  case  the  debugger  -  should  support  these  aspects 
of  the  language.  In  the  following  some  examples  are  given  on  Ada  specific 
features  that  should  be  supported,  and  how  they  are  handled  by  the  DDC-I 
debugger. 

The  first  facility  to  be  thought  of  is  tasking.  The  tasking  model  is  an 
integrated  part  of  Ada;  an  Ada  debugger  should  therefore  be  able  to  handle 
programs  with  concurrent  tasks.  This  means,  that  a  strategy  must  be  decided 
for  handling  the  situation  where  several  tasks  are  or  may  become  breaked 
(l.e.  suspended  on  a  breakpoint);  and  the  control  structure  of  the  debugger 
must  be  prepared  for  asynchronous  events.  Furthermore,  the  debugger  should  be 
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able  to  handle  the  task  states  as  defined  by  Ada.  The  current  state  of  a  task 
like  "caller  in  rendezvous",  "delayed*  and  "waiting  for  accept"  and  state 
information  like  current  or  expected  rendezvous  partner  should  be  available, 
as  well  as  information  about  the  task  structure  like  the  names  of  the  parent 
and  the  children  tasks.  Furthermore,  the  debugger  should  be  able  to  set 
breakpoints  at  task  events  like  task  activation,  rendezvous,  termination, 
abortion  and  completion. 

The  DOC'l  debugger  supports  debugging  of  Ada  programs  with  tasks.  A  strategy 
and  a  series  of  commands  for  handling  several  simultaneously  breaked  tasks 
and  allowing  the  user  to  inspect  the  different  tasks  have  been  designed.  An 
extended  visibility  concept  has  been  designed,  allowing  the  inspection  of  the 
context  of  the  different  tasks  as  well  as  the  value  of  objects  declared 
inside  package  bodies.  This  extended  visibility  concept  allows  you  to  Inspect 
the  state  of  the  entire  system  while  debugging.  Instead  of  limiting  you  to 
the  entities  visible  from  the  breakpoint  on  which  your  program  (task)  is 
currently  suspended.  This  facility  is  particularly  important  in  systems, 
where  the  state  of  one  part  of  the  system  may  affect  the  data  produced  by  an 
other  part  of  the  system,  as  is  the  case  in  e.g.  regulation  systems  with 
feedback. 

As  stated  above,  it  should  be  possible  -  using  the  debugger  ~  to  display  the 
entire  task  structure  and  the  task  states  of  the  program  and  to  set 
breakpoints  at  task  events.  Only,  in  order  to  do  this,  you  need  a  unique 
identification  for  each  task.  As  Ada  allows  the  dynamic  creation  of  tasks, 
the  Ada  name  for  a  given  task  may  not  be  designating  a  unique  task,  as 
several  instances  of  that  task  may  exist  in  the  program  at  a  given  point  of 
execution.  The  DDC-1  debugger  therefore  assigns  a  unique  task  identification 
to  each  'task  in  the  system.  The  user  may  then  use  the  Ada  name  when 
referencing  tasks  that  are  visible  from  the  current  viewpoint  (point  of 
execution  of  the  currently  breaked  task,  which  is  being  inspected);  tasks 
that  are  not  visible  may  be  referenced  by  means  of  the  task  identification. 
The  visible  tasks  may  of  course  also  be  referenced  by  their  task 
identification  if  the  user  wishes  to  do  so. 

Another  important  feature  of  Ada  is  the  built-in  checks  and  the  ability  of 
well-controlled  error  handling  -  the  exception  mechanism.  In  Ada,  it  is 
checked  dynamically  that  the  executed  code  is  legal;  as  an  example,  when  a 
value  is  assigned  to  an  object,  it  is  checked  whether  this  value  la  within 
the  legal  set  of  values  (the  constraints)  for  that  object,  and  if  not,  an 
exception  is  raised.  The  user  may  define  his  or  her  own  error  conditions  and 
associate  a  named  exception  to  a  given  condition. 

When  the  user  during  a  debugging  session  wishes  to  change  the  value  cf  an 
object  in  the  target  program,  the  DOC-I  debugger  performs  the  checks  defined 
by  Ada:  If  the  assigned  value  is  not  legal,  an  error  is  reported.  The  DDC-I 
debugger  also  allows  the  user  to  set  a  breakpoint  on  the  raise  of  a  specific 
exception  (or  on  all  exceptions)  in  order  to  detect  possible  error  conditions 
and  investigate  how  they  are  handled.  Furthermore,  It  is  possible  when  using 
the  debugger  to  explicitly  raise  an  exception  in  the  user  program  in  order  to 
test  the  handling  of  e.g.  hardware  failures,  which  may  otherwise  be  difficult 
to  simulate. 

The  last  Ada  feature  to  be  used  as  an  example  here  is  the  PRAGMA  INLINE,  This 
feature  allows  the  programmer  to  structure  a  program  neatly  by  defining 
subprograms  without  havir^  to  pay  the  efficiency  penalty  of  a  subprogram 
call.  If  a  given  subprogram  is  mentioned  in  a  PRAGMA  INLINE,  the  code  of  the 
subprogram  is  expanded  at  the  place  of  the  call;  no  call  code  is  generated. 

Most  Ada  debuggers  do  not  support  PRAGMA  INLINE.  Why  is  INLINE  difficult  from 
a  symbolic  debugging  point  of  view?  Basically,  because  the  same  source  text 
statement  or  declaration  correspond  to  several  different  entities  of  code. 

The  DOC-I  debugger  supports  PRAGMA  INLINE.  A  strategy  and  a  set  of  commands 
for  designating  and  handling  a  specific  Inline  expanded  call  has  been 
designed.  It  is  worth  noting,  that  the  choice  to  support  PRAGMA  INLINE 
affects  the  entire  mechanism  for  looking  up  names  and  deciding  visibility;  it 
is  thus  not  a  facility,  which  may  be  "added  on  later". 

This  concludes  the  description  of  how  the  first  of  the  three  debugger  project 
goals:  to  support  the  features  of  Ada  properly  has  been  achieved.  In  the 
remaining  part  of  the  paper  the  achievement  of  the  two  remaining  goals:  to  be 
useful  for  debugging  embedded  real-time  applications  and  to  be  easily 
portable  are  treated. 


Portability  and  Efficiency 


Portability  of  a  tool  is  important,  because  it  allows  the  maximum  number  of 
users  on  various  systems  to  profit  from  the  tool  with  the  minimum  amount  of 


time  and 
the  sane 


effort, 
tool  on 


Furthermore,  the  learning  overhead  is  minimized  by  using 
different  systems;  end  reuse,  which  is  one  of  the  key 
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concepts  of  Ada.  Is  facilitated  by  portability. 

The  Ada  compiler  system,  of  which  the  debugger  referred  to  in  this  paper  is  a 
part,  has  been  ported  to  a  number  of  different  development  systems  with  hosts 
ranging  from  mainframes  to  mini  computers  and  targets  ranging  from  bare 
microprocessors  to  mainframes.  Portability  is  therefore  a  key  issue  for  this 
debugger  project. 

Easy  portability  of  a  debugger  is  not  simple  to  achieve,  as  a  debugger 
Inherently  manipulates  machine  dependent  data. 

The  reason  for  treating  the  two  goals:  "Usefulness  for  embedded  real-time 
applications"  and  "lortability"  together  is  that  there  is  a  potential 
conflict  between  the  two  goals.  Portability  in  debuggers  is  often  achieved  by 
relaxing  the  demands  for  target  program  efficiency  -  in  terms  of  speed  and 
storage  requirements  -  when  debugging.  Some  debuggers  rely  on  calls  to 
special  debugging  routines  to  be  inserted  at  all  potential  breakpoint 
positions  in  the  original  program  code.  In  this  way,  the  debugger  is  made 
portable  as  no  knowledge  of  physical  addresses  is  required  by  the  debugger. 
The  insertion  of  calls  to  debugging  routines  is  called  "instrumenting  the 
code " . 

This  approach  is  not  acceptable  for  real-time  embedded  applications  due  to 
its  effects  on  target  program  efficiency.  The  target  program  execution  is 
slowed  down  considerably,  causing  the  timing  behaviour  of  the  target  system 
to  change.  Errors  may  change  or  even  disappear  when  the  code  containing  the 
debug  calls  is  executed;  or  -  even  worse  -  critical  system  deadlines  may  be 
missed,  causing  other  problems.  Furthermore  the  storage  requirements  of  the 
program  are  increased;  in  the  extreme  case,  the  needs  of  the  debugger  may 
cause  the  target  program  to  grow  to  a  size  which  makes  it  Impossible  to 
execute  on  the  target  system. 

The  debugger  referred  to  In  this  paper  is  designed  to  require  minimal 
interference  with  the  target:  No  insertions  in  the  target  code  are  necessary. 
How  is  this  achieved,  and  what  is  meant  by  still  stating  that  the  debugger  is 
easily  portable? 

The  requirement,  that  no  insertions  in  the  target  code  must  be  relied  on. 
means  that  address  information  has  to  be  handled  on  the  host,  and  if  the 
debugger  is  to  be  easily  portable,  preferably  by  the  portable  parts.  This  is 
achieved  by  defining  a  set  of  data  structures  (tables),  containing  the 
information  necessary  for  translating  between  source  text  positions  and 
physical  adresses.  The  relations  between  the  tables  reflect  the  structure  of 
the  original  source  text. 

The  tables  are  built  as  follows.  The  portable  parts  of  the  compiler  (the 
front  end)  generates  the  Information  about  the  program  structure.  The  non¬ 
portable  parts  of  the  compiler  (the  back  end)  adds  information  about  the 
relative  addresses  of  the  structures.  Finally  a  portable  tool  builds  the 
tables,  adding  the  information  about  absolute  addresses  obtained  from  the 
linker. 

When  the  user  wants  to  set  a  breakpoint  during  a  debugging  session,  these 
tables  allow  the  portable  parts  of  the  debugger  to  translate  the  Ada  source 
text  position  entered  by  the  user  to  the  address  of  the  corresponding  code  on 
target.  A  breakpoint  can  then  be  introduced  at  that  address  on  the  target. 

This  approach  means  that  no  change  or  overhead  in  the  target  program 
execution  occur,  except  at  the  breakpoints  Introduced  by  the  user. 
Furthermore  it  means  that  all  the  information  necessary  for  the  debugger  is 
stored  on  the  host;  no  extensive  target  storage  requirements  are  introduced 
by  the  debugger. 

The  target  system  interference  required  is  then  basically  reduced  to  read  and 
write  operations  on  target  memory  and  registers,  and  this  Is  only  done  when 
the  target  program  is  suspended  because  a  breakpoint  has  been  encountered. 

Some  of  the  features  of  the  debugger  may  though  require  changes  in  the  run 
time  system.  One  example  is  the  facility  of  forcing  a  task  to  be  suspended 
until  explicitly  released  by  the  user:  An  additional  task  state  value  may 
have  to  be  added. 

In  some  applications  this  may  not  be  acceptable.  In  order  to  allow  for 
different  user  requirements  depending  on  the  application,  and  for  different 
levels  of  system  debugging  support,  the  debugger  is  configurable:  When 
implementing  the  debugger  on  a  given  host/target  system,  the  Implementor  may 
choose  to  implement  or  leave  out  any  facility.  This  is  yet  another  aspect  of 
making  the  debugger  easily  portable. 

So.  to  summarize,  what  is  meant  by  stating  that  the  debugger  is  easily 
portable? 
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>  th«  maximun  amount  of  debugger  processing  is  carried  out  by  the  portable 
parts 

•  the  target  (and  host)  interfaces  are  isolated  and  well-defined 

-  the  data  structures  for  information  to  be  provided  by  target  dependent 
parts  are  defined  and  prepared  to  be  filled  out,  and  a  portable  tool  for 
building  address  information  is  provided 

-  the  debugger  is  configurable,  allowing  for  different  applications  and 
different  levels  of  system  debugging  support 

And  what  is  meant  by  stating  that  the  DDC-I  debugger  requires  only  the 
minltnum  target  system  interference: 

-  the  debugger  requires  no  instrumentation  of  the  code 

-  the  debugger  may  be  configured  such  that  no  interaction  with  the  target  or 
additional  overhead  is  required  during  target  program  execution  between 
breakpoints 

-  the  interactions  with  the  target  during  program  execution  may  be  reduced 
to  read/write  operations  on  target  memory 

-  the  debug  information  is  stored  on  the  host 

-  all  debugger  processing  of  symbolic  information  is  performed  on  the  host 


Conclusion 

Some  features,  which  tools  for  developing  real-time  embedded  systems  in  Ada 
should  have,  ware  presented  in  the  paper,  using  the  experience  gained  from 
the  DDC-1  symbolic  debugger  project  it  was  demonstrated  how  a  specific  tool, 
a  debugger,  has  been  brought  to  possess  these  features. 


DISCUSSION 


W.ManacI,  Ge 

1 .  How  is  the  host^target  iinJc  realized  for  transferring  debugging  data  from  the  target  to  the  host?  Is  it  done  via 
RS232  serial  link?  Is  high  speed  access  via  emulation  possible? 

2.  What  information  can  be  gathered  by  task  debugging?  Are  the  task  control  blocks  accessible? 

Author's  Reply 

1 .  The  debugger  structure  is  designed  to  allow  the  use  of  any  means  available  for  host/target  connection,  including 
emulators.  The  first  debugger  targeting  to  be  done  by  DCKT-I  (to  the  Intel  80  X  86  processor  family)  is  to  use  a 
serial  link  (RS232  or  similar),  but  it  is  likely  that  we  will  make  an  emulator>based  version  later. 

2.  When  debugging  tasks,  information  is  available  about  the  Ada  task  structure,  i.e.,  the  task  ids,  the  current  task 
states  as  defined  in  Ada,  the  task  priorities  as  well  as  the  current  entry  queues,  caller  in  rendezvous  etc.  We  have 
tried  to  provide  all  the  information  one  could  ever  wish  to  have.  Therefore  it  should  normally  not  be  necessary  to 
look  at  the  Task  Contr(^  Block;  but  if  you  still  want  to  look  at  the  TCB,  it  is  possible  to  use  the  machine  level 
features  of  the  debugger  to  display  the  contents  of  the  TCB. 


M.Muinkr,  Fr 

1 .  How  can  you  deal  with  acquiring  (tracing)  dynamically  allocated  data? 

2.  To  what  extent  is  your  80  x  86  system  dependent  on  the  RTS  you  developed? 

Author's  Reply 

1 .  We  use  our  knowledge  about  the  compiler  strategy  for  data  layout  and  the  information  present  in  the  symbol 
tables  stored  in  the  Program  Library. 

2.  The  80  X  86  compiler  is  already  being  used  with  one  externally  manufactured  Run-Time  System  and  another  one 
is  planned.  The  Run-Time  System  Interface  is  described  in  a  document  and  any  Run-Time  System  adhering  to  this 
interface  can  be  used.  Therefore  the  compiler  does  not  depend  on  the  RTS. 

The  debugger  interpret  RTS  data  structure  parts  depend  on  the  RTS  and  would  have  to  be  rewritten  if  a  different 
RTS  is  to  be  used.  I  would  consider  this  a  minor  effort  though,  as  the  major  parts  of  the  target  dependent  parts  of 
the  debugger  only  rely  on  compiler  generated  information. 
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SUMMARY 

Th«  ««rl<Ki«  pr«ctlc*  of  oofevoro  eaglneorlng  lo  m  rolatlvoly  rocont  ph«oo«onoii  and  there  hae  been  a 
■Inlatai  of  reported  experience  In  the  uee  of  nethoda  and  toola  to  support  its  application. 

Tha  technology  can  be  viewed  aa  progreaalng  through  aeveral  generatlona  typified  by  the  fora  in 
which  development  Information  la  stored  and  acceaaed  and  the  nature  of  the  lifecycle.  The  former 
is  described  in  terms  of  a  file,  data  and  a  knowledge  base,  the  latter  aa  progressing  from  a  phase 
to  an  object  orientated  lifecycle. 

Experience  with  a  typical  first  generation  toolset  Is  described  briefly  through  the  airborne 
software  for  tha  Experimental  Aircraft  Project.  This  is  based  largely  on  the  use  of  structured 
methods  for  requirements  and  design,  a  programming  support  environment  supporting  the  use  of  MASCOT 
and  Pascal  and  rigorous  management  and  control  procedures.  An  advantageous  cost  benefit  analysis 
of  the  project  la  reported. 

A  move  to  the  second  generation  of  software  engineering  Is  being  planned  under  the  auspices  of  the 
Eurofighter  Project  by  the  adoption  of  a  Integrated  Project  Support  Environment  (IPSE). 

The  general  characteristics  of  an  ZPSC  are  discussed  Including  the  tool  Interface  and  its  relevance 
to  emerging  standardisation  activities  such  as  CAIS  and  PCTE  Plus. 

A  longer  term  view  of  software  Is  presented  with  an  Intimation  of  the  scale  and  nature  of  future 
projects  and  a  new  fora  of  lifecycle  better  suited  to  their  needs.  The  requirements  for  software 
engineering  to  support  artificial  Intelligence,  safety  critical  applications  and  rapid  prototyping 
are  reviewed. 

INTRODUCTION 

In  this  paper  va  will  be  discussing  three  generations  of  Software  Engineering  but  It  would  be 
useful  to  preface  It  with  some  simple,  definitions  and  a  down  to  earth  assessment  of  the  state  of 
tha  act. 

Boehm  (1)  makes  a  useful  attempt,  by  first  defining  software  and  engineering  Individually  and  then 
synthesising  an  acceptable  overall  definition. 

Software  is  the  set  of  programs,  procedures  and  related  documentation  associated  with  a  system  and 
sspeclslly  s  computer  system. 

Engineering  Is  the  application  of  sclenca  and  mathematics  by  which  the  properties  of  matter  and  the 
sources  of  energy  In  nature  are  made  useful  to  mao  In  structures,  machines,  products,  systems  and 
processes. 

Hence,  software  engineering  Is  the  application  of  science  and  mathematics  by  which  the  capabilities 
of  computer  equipment  are  made  useful  vis  computer  programs,  procedures  and  associated 
documentation. 

However,  an  anglocer  in  more  traditional  diaclpllnes  conceives  a  design  to  satisfy  a  requirement 
based  on  tha  use  of  modified  or  processed  forms  of  raw  material  with  known  properties,  ^ere  are 
catalogues  of  readily  available  components  with  stated  qualities  (both  static  and  dynamic)  from 
which  to  choose.  Finally,  there  la  an  undaxstaadlng  of  how  they  will  fit  and  perform  together 
which  to  a  large  extent  Is  predictable. 

Thia  process  Is  supported  by  many  (sometimes  hundreds)  of  years  of  science  being  applied  to 
understanding  the  properties  of  materials  and  components,  again  both  statically  and  dynamically. 
Mathematics  has  been  a  nccesaary  component  in  developing  this  understanding  and  the  whole  la 
underwritten  by  a  mass  of  test  data. 

Hence  va  nay  talk  with  soma  confidence  about  software  management  or  order  and  list  tools  and 
mathoda  whoaa  functions  have  to  a  large  extent  bean  derived  enplrli  ally  but  thla  does  not 
constitute  englneariog  In  the  traditional  sanae. 

Taking  thla  simple  parallel  with  eradftlonal  engineering  a  stage  further  there  Is  another 
fundamental  difference  between  how  the  two  communitiee  approach  their  work.  Today's  designer  «rould 
rarely  consider  it  worthwhile  to  leave  his  drsvlng  bosrd  for  the  workshop,  roll  up  his  sleeves  and 
nmnufactura  his  dsslgn.  Similarly  tha  machinist  who  produces  an  Individual  component  would  not 
expect  to  be  involved  In  fitting  It  into  the  overall  structure. 
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Software  daalgnara,  particularly  in  Mall  organlaationa*  fusetloo  vary  aueh  Ilka  tha  original  and 
hlj^ly  aklllad  anginaara  who  aat  tha  paca  la  Innovatlva  anglnaarlng  prior  to  tha  ara  of  large  scale 
production*  They  sketch  an  outline  design,  specify  It  In  nora  detail,  laplenent  it  at  tha  coding 
level  and  than  use  Individual  nodules  to  construct  an  overall  systaa  giving  them  responsibility  for 
design,  Isplanentatlon  and  testing. 

They  ara  true  artisans  and  It  Is  not  surprising  that  sons  of  tha  tools  that  have  bean  produced  to 
help  than  reflect  this  view  whan  they  ara  referred  to  as  software  designer's  or  prograaser's 
’Srorkbenches" *  However,  as  systMs  have  becone  larger  there  has  been  a  gradual  drift  totrards  the 
■ethods  of  nass  production  end  the  segregation  of  the  various  tasks  Involved  In  production.  A 
designer  at  a  particular  level  need  not  be  involved  at  the  lapleaantatlon  stage  and  whoever  is 
responsible  for  laplenentlng  particular  nodules  would  test  than  Individually  before  passing  then  to 
a  "systens  Integrator**  to  use  then  In  systen  construction. 

With  the  engineering  of  hardware  the  envlronnencs  associated  with  design  office,  workshop  and  test 
house  are  vastly  different  and  are  tailored  to  neet  the  needs  of  staff  involved  In  each  of  these 
activities.  This  reflects  a  fundanental  understanding  of  ths  process  that  each  envlronnent  is 
helping  to  support  including  the  nature  of  the  work  and  the  skills  and  tools  required  to  do  the 
job. 

He  are  nany  years  away  fron  the  sane  level  of  understanding  In  software. 

Progress,  however.  Is  visible  as  this  paper  attesq>ts  to  show  by  desc-lblng  the  transition  through 
successive  levels  of  software  engineering.  This  passage  la  witnessing  a  greater  understanding  of 
the  developnent  process  and  an  Increase  in  the  degree  of  formality  used  for  expression,  both  of 
which  are  imperative  if  the  engineering  of  software  is  to  approach  its  traditional  counterpart. 

THE  nRST  GEWERATIOW 


In  1978  British  Aerospace  approved  a  small  prograame  of  research  to  examine  ways  In  which  the 
quality  of  evlonlc  software  requirements  could  be  Improved.  A  esse  had  been  made  by  pointing  out 
the  high  leverage  of  good  quality  requirements  on  the  subsequent  Implementation  of  software.  This 
work  was  given  further  impettts  by  the  growing  realisation  that  If  the  airborne  software  for  the 
next  foreseeable  project  was  to  be  implemented  at  productivity  levels  found  on  current  aircraft 
projecta  It  could  exceed  1000  man  years. 

The  Initial  programme  focussed  on  system  end  software  requirements  but  the  scope  of  the  project 
grew  until  a  set  of  methods  end  tools  emerged  covering  the  complete  lifecycle  of  software.  The 
techniques  were  evaluated  individually  on  a  number  of  small  projects  but  became  fully  integrated 
and  used  on  a  project  of  appropriate  scale  with  the  Experimental  Aircraft  Programme. 

Collectively  they  represent  a  particular  standard  of  software  engineering  beeed  on  a  structured 
epproech  to  requirements  snd  design  bsssd  predominantly  on  the  use  of  dlagrsma.  Language 
Independent  detailed  deelgn  it  linked  to  proceduree  for  code  production  using  dlffersnt 
Implementation  languages.  Software  construction  employs  s  programming  support  environment  working 
on  the  hoet/target  principle  and  support  tools,  in  the  main,  are  file  based.  This  has  been 
classified  as  s  first  generation  of  software  engineering. 

SAFRA 

The  overall  approach  Is  entitled  Semi  Automated  Functional  Requirementa  Analysis  (SAFRA)  and  is 
based  upon  the  widely  accepted  phase  oriented  lifecycle  model.  This  Is  Illustrated  in  Pig.  (1) 
together  with  Che  methods  and  tools  employed  during  each  phase  and  these  are  described  briefly 
below. 

The  technique  used  to  develop  snd  express  requirsments  is  Controlled  Requirements  Expression 
(CORE  CORE  provides  the  msans  to  analyse  and  express  requirements  in  s  controlled  and  precise 
manner  using  mainly  diagrams  to  represent  data  flow  and  data  decomposition.  The  method  co^rlsea 
eleven  logical  staps  which  when  applied  to  a  subject  requirement  will  decompose  It  Into  Its  lower 
level  components.  A  CORE  workstation  (CHS)  provides  s  means  of  constructing,  editing  snd  analysing 
diagrams  for  consistency  and  completeness. 

CORE  products  may  be  subjected  to  more  detailed  analysis  by  use  of  PSL/PSA  (Problem  Statement 
Language/Problem  Statement  Analyser).  PSL  is  an  English  Ilka  languaga,  with  a  range  of  appropriate 
object  types,  capable  of  describing  both  architectural  and  behavioural  aspacts  of  aystams.  PSA 
provldas  a  range  of  reports  that  will  analyse  the  accuracy  of  PSL  descriptions. 

The  Interface  between  requirements  and  software  design  sssumss  ths  uss  of  MASCOT  (Modular  Approach 
to  Software  Construction  Operation  and  Test).  MASCOT  views  s  basic  software  design  as  a  nu^ar  of 
activltiea  which  operate  Independently  and  asynchronously  but  which  co-operats  by  accssalng  shared 
Interconmunlcatlon  Data  Areas  (IDA's)  which  can  bs  either  channals  or  pools.  Integrating  a 
requirements  phase  using  CORE  with  a  basic  design  phase  using  MASCOT  Is  achieved  by  transforming  a 
CORE  requirement  diagram  Into  a  MASCOT  design. 

Detailed  design  for  activities  involves  normal  structured  program  design,  continuing  to  use  CORE 
notation,  and  coding  may  be  done  in  CORAL  or  Pascal.  The  software  construction  snd  testing  phases 
make  use  of  the  PERSPECTIVE  programming  support  environment  produced  by  Systems  Desi^ers, 
PERSPECTIVE  allows  the  Incremental  construction  of  software  systems  snd  their  testing  In  s  host 
machine  and  tha  target  procassor  which  Is  part  of  the  avionic  system.  It  also  actively  supports 
configuration  management  and  so  helps  to  ensure  that  valid  versions  of  software  components  are  used 
in  system  construction. 


In  Kny  1983»  British  Asrospncc  signed  s  contrsct  vlth  the  UK  Ministry  of  Dsfencs  to  design  end 
produce  s  new  sircrsft  ss  s  technology  deaonstrstor,  the  progrsMS  to  be  known  as  the  ExperlJMntal 
Aircraft  Programs  (EAP).  The  alas  of  the  programs  being  to  bring  together  a  specific  range  of 
new  and  advanced  technologies  being  developed  by  British  Aerospace  and  other  aerospace 
aanufacturers  in  Europe. 

EAP  is  a  slngls'seat  twin-engined  aircraft »  powered  by  two  uprated  versions  of  Tornado's 
Turbo-Onion  RB-L99  engines.  It  has  all  moving  foreplanes  (canards)  and  an  advanced  coapound  strept 
wing.  It  is  designed  to  prove  in  a  one-off  deaonstrator  the  latest  technologies  which  have  been 
the  subject  of  separate  govemaent  research  contracts  over  the  past  decade.  The  various 
technologies  being  tested  and  integrated  into  this  deaonstrator  are  utilised  in  the  tour  nation 
European  Fighter  Aircraft  (EFA)  project  currently  being  developed. 

Soae  50Z  of  the  UK  costs  have  been  provided  by  HH  Govemaent  as  its  contribution  to  the  design  and 
building  of  this  aircraft.  The  balance  has  been  found  by  British  Aerospace  and  its  UK  and  European 
partners. 

The  aaln  areas  of  advanced  technology  are  to  be  found  in  the  active  flight  control  systea»  the 
avionics  suite,  the  extensive  use  of  carbon  fibre  coaposltes,  alualniua  llthlua,  and  in  the  use  of 
super-plastic  foraing  and  diffusion  bonding  techniques  in  the  alrfraae  construction. 

The  EAP  systea  architecture  conprises  three  aajor  sub-systeas:- 

*  Flight  Control  Systea  (PCS) 

*  Utilities  Systeas  Manageaent  Systea  (USMS) 

*  Avionics 

Coanunications  between  the  three  sub-systeas  is  achieved  via  Remte  Teralnala  on  the  aain  Avionics 
data  highway.  The  PCS  was  a  derivative  of  the  existing  Jaguar  Ply-by-Wlre  deaonstrator  aircraft 
systea.  However  the  USHS  and  Avionics  systeas  represent  new  design  work  and  SAFRA  was  specified  as 
the  tocltet  to  be  used  for  the  specification  and  design  of  these  sub-systeas. 

The  USM  Systea  is  responsible  for  software  control  of  aany  of  the  aechanlcal  aircraft  systeas  that 
have  traditionally  been  controlled  by  analogue  aeans  and  exaaples  Include  Hydraulic  control,  Fuel 
Manageaent  and  Braking  systems.  The  Avionics  systea  provides  the  processing  of  raw  sensor  data, 
overall  systea  and  displays/controls  aoding  and  the  generation  of  a  wide  range  of  aultifunctlon 
cockpit  displays.  It  also  has  executive  control  of  the  total  systems,  including  bus  transactions 
and  remedial  actions  in  the  event  of  failures. 

Prellatnary  Results  from  EAP 

Comparisons  have  been  made  between  producing  the  software  for  EAP  end  avionic  software  from 
previous  projects,  looking  first  at  the  gains. 

*  Errors  are  detected  sooner;  early  experience  %rlth  Tornado  had  prompted  the  use  of  more 
dynamic  testing  techniques  to  clear  the  Air  Defence  Variant  software  on  the  rig.  This 
caused  a  significant  shift  from  the  aircraft  to  the  rig  in  detecting  problems.  The 
evidence  on  EAP  shows  that  problems  were  being  detected  much  earlier  in  the  lifecycle. 

”  Quality  of  delivered  software  is  Improved;  comparing  EAP  with  the  most  previous  example  of 

avionic  software  to  go  through  flight  clearance  testing  on  the  rig  shows  that  quality  has 
improved  by  almost  a  factor  of  ten. 

*  Less  resources  are  needed  for  rig  testing;  improvements  In  quality  have  led  to  reductions 
in  the  volume  of  testing.  Test  schedules  are  still  exhaustive  but  the  amount  of  retesting 
as  a  consequence  of  change  is  now  much  less. 

"  Productivity  is  higher;  the  two  most  recent  projects  were  experiencing  individual 

productivity  of  about  250  lines  of  code  per  man  year  for  software  design,  code  and  test. 
The  average  productivity  achieved  on  EAP  was  1400  lines  of  code  per  man  year. 

Less  quantifiable  gains  are  typified  in  the  approach  providing  a  detailed  framework  for  training 
(rather  than  learning  on  the  Job).  This  meant  that  a  comprehensive  and  detailed  training  scheme 
could  be  planned  which  in  turn  led  to  teams  being  formed  reasonably  quickly  from  relatively 
Inexperienced  personnel.  It  also  demonstrated  that  putting  more  people  on  software  projects  can 
make  then  earlier,  albeit  at  the  expense  of  Individual  productivity. 

The  introduction  of  the  approach  did  encounter  some  problems: 

*  There  was  some  preliminary  resistance  to  the  use  of  SAFRA  which,  although  it  was  overcome 
as  benefits  emerged,  could  have  been  reduced  by  better  education  in  the  value  and  role  of 
SAFRA. 


Some  of  the  tools  were  lamature  demonstrating  the  limitations  of  using  small  evaluation 
projects  to  fully  prove  a  technique.  Availability  did  not  necessarily  mean  maturity. 


New  tools,  quite  naturally,  will  still  be  evolving  and  this  can  potentially  have  a 
disastrous  effect  in  a  project  context.  Proposed  developments  must  be  identified  and 
special  arrangements  made  to  freete  tools  if  necessary. 
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SAFRA  corrMponda  to  a  flraC  Softwara  Enginaarlng  tachnology.  The  toola  ara 
pradOBinancly  file  baaad  and  laCagraClon  la  funcClooal  rathar  Chao  inCarnal.  Soaa  llalcaciona  irlch 
chia  atandard  iocludat- 

*  cha  problaa  of  aabodying  additional  or  dlffarant  toola 

*  tha  aaaoa  of  autoaatlng  tha  anforcamant  of  configuration  control  and  managanant  proeaduraa 
over  tha  vhola  llfacycla. 

Theaa  llaltatlona  will  ba  llftad  with  tha  advant  of  a  2nd  ganaratlon  of  softwara  anglneerlng 
typlflad  by  tha  uae  of  Intagratad  Projact  Support  Envlronnanta  (IPSE). 

THE  SECOHD  GEWERATIOH 

Tha  looaa  coupling  of  tools  typlflad  by  cha  First  Ganaratlon,  rellas  on  sealous  application  of 
manual  configuration  aanagamant  and  control  proeaduraa  to  handle  the  transposition  from  tha  file 
store  of  one  tool  to  tha  next.  While  this  Is  practicable  In  tha  context  of  a  relatively  small 
project,  such  as  EAP.  It  is  inadequate  for  a  large  international  projact  of  the  scale  of 
Euroflghter. 

This  project  la  likely  to  be  at  leaat  an  order  of  magnitude  greater  chan  EAP,  the  Implementation 
will  be  much  more  widely  distributed  and  development  will  take  place  over  a  longer  period  of  time. 
It  can  be  argued  that  the  nature  of  methods  and  tools  being  used  will  reaiain  about  the  same. 

Structured  methods  will  be  used  for  requirements  analysis  and  detailed  software  design,  while  basic 
design  will  be  supported  by  a  hl^  degree  of  modularisation  chat  will  map  on  to  the  higher  order 
language,  Ada.  The  latter  will  use  a  compiler  Chat  allows  host/target  testing. 

However,  the  volume  of  design  Information  produced  over  the  complete  lifecycle  of  the  Euroflghter 
implementation  demands  much  more  Chan  a  loose  coupling  of  tools  through  individual  files,  it 
requires  a  single  repository  of  information  in  the  form  of  a  centralised  database. 

As  Tim  Lyons  argues  in  (2)  Che  essential  part  of  any  support  environment  Is  the  ability  to  store 
data.  Projects  typified  by  Euroflghter  will  have  an  enormous  amount  cf  data,  embracing 
requirements,  specifications  and  design  documents,  test  schedules,  source  code,  object  code, 
executable  binary  Images  and  management  and  control  information,  to  date  this  has  resided  in  the 
individual  files  of  cools  appropriate  to  each  function. 

However,  Che  Information  chat  a  project  needs  to  store  consists  of  not  only  these  individual 
entitles  but  also  the  relationships  between  them.  These  relationships  include  those  between  source 
and  object  file,  design  and  specification  and  the  connection  between  a  change  and  a  error  report. 

The  notion  of  a  database  as  the  centre  of  an  environment  Is  to  provide  explicit  support  for 
representing  any  of  the  data  normally  held  in  a  file,  but  also  the  relationships  between  the  data. 
The  database  provides  support  not  only  for  representing  data  items  but  for  representing  the 
structure  of  data. 

Clearly  the  existence  of  such  a  mechanism  provides  the  basis  for  rationalising  the  interface 
between  the  database  and  Che  cools  that  will  make  use  of  it.  This  interface  is  popularly  referred 
to  as  the  Public  Tool  Interface  (PTI)  for  an  IPSE  and  is  shown  schematically  in  Figure  2.  The 
Figure  goes  further  in  that  It  Illustrates  Che  other  skins  around  Che  database  that  may  or  may  not 
be  an  integral  part  of  the  PTI.  These  include  the  version  and  variant  control  aspects  and  the 
rationale  of  how  the  user  Interacts  with  tools.  An  example  of  Che  latter  is  standardising  on  a 
particular  style  for  editing  or  Che  provision  of  help  Information. 

The  model  also  accepts  the  notion  of  the  unpopulated  IPSE  being  used  on  different  projects  with 
appropriate  tools  and  those  specific  to  a  particular  organisation  or  company.  This  includes  tools 
developed  independently  of  the  IPSE  <3rd  party  tools)  and  those  that  will  not  Interface  through  the 
intimate  connection  of  the  PTI.  The  latter  will  occur  when  tools  already  exist,  are  not  required 
as  intensively  throughout  the  project  and  Che  cost  or  technical  difficulty  of  such  an  Interface  is 
beyond  the  scope  of  Che  user.  This  latter  foreign  tool  interface  is  more  likely  to  be  at  a  file 
rather  than  at  the  detailed  object  level. 

While  a  growing  number  of  proprietary  1?SE*8  with  tool  interfaces  of  this  kind  are  beginning  to 
emerge  there  Is  also  considerable  Interest  In  PTI's  as  a  standardisation  activity.  Such  a  move  Is 
unique  (and  somewhat  adventurous)  against  a  background  of  very  little  experience  in  the  use  of 
IPSE*e.  However,  work  on  both  sides  of  the  Atlantic  is  pursuing  the  objective  of  a  standard  for 
particular  PTI*s  through  the  CAIS  and  PCTE  progrsBes  of  work. 

In  1982  the  US  Ada  Joint  Programme  Office  established  a  Joint  service  team  known  as  the  KAPSE 
Interface  Team  (KIT)  and  a  complementary  industry /academia  team  (KTTIA).  The  object  of  the  team's 
work  was  to  co-operate  and  converge  on  a  set  of  Ada  Programing  Support  Environment  (APSE) 
Interface  standards  to  permit  the  sharing  of  tools  and  other  software  between  DOD  supported  APSEs. 
KIT  and  KITIA  have  developed  a  Military  Standard  Co«BK>n  Apse  Interface  Set  (CAIS)  and  in  parallel 
have  also  developed  the  requlrraents  for  a  more  advanced  interface  set  which  Is  being  developed  by 
s  US  Industrial  Consortia. 

In  Europe,  a  consortium  under  ESPRIT  are  developing  a  system  as  a  basis  for  a  Portable  Common  Tool 
Environment  (PCTE).  The  PTI  of  this  system  is  intended  as  a  common  platform  on  which  tools  can  be 
built,  both  within  the  ESPRIT  prograve  and  elsewhere.  PCTE  continues  to  be  developed  as  part  of  a 
further  European  prograve  (under  IEPC/TA13)  towards  an  enhanced  civil  as  well  as  military 


•tAodard.  Thla  is  dus  to  sntsr  tbs  l^lsasntstlon  sod  ssssssasnt  phase  in  the  near  future.  It  is 
hoped  that  there  could  be  conversions  of  the  QS  and  European  standards »  possibly  under  the  auspices 
of  KATO. 

THE  THIRD  GEHERATIOM 

Aerospace  software  projects  continue  to  represent  some  of  the  nost  challenging  examples  of  large 
real-time  ciri>edded  systems.  Projects  with  lifecycles  In  excess  of  15  years  arc  not  uncoamon  and» 
even  with  Che  highest  productivity  currently  available*  implementations  can  number  several  hundred 

nan  years. 

Airborne  applications  in  Che  last  two  decades  have  reached  several  hundred  thousand  lines  of  code* 
during  Che  early  90 's  systems  arc  oMre  likely  to  contain  several  million  lines  of  code.  In  order 
to  contain  the  human  resources  required  we  seek  productivity  improvement  to  match  this  growth. 

An  order  of  magnitude  Improvement  over  current  projects  is  the  eventual  target. 

The  need  is  compounded  by  other  industrial  sectors  experiencing  a  similar  growth  of  software  in 
their  products  and  competing  for  the  services  of  the  same  people  required  by  Aerospace. 

A  similar  growth  is  to  be  found  in  the  scale  of  safety  critical  systems  as  shown  in  figure  3* 
illustrating  that  improvements  in  productivity  must  not  be  at  the  expense  of  qusllty.  The  major 
advance  between  the  lower  points  and  EFA  are  the  likely  move  towards  the  use  of  a  safe  sub-set  of  a 
higher  order  language  and  formally  based  code  analysis  tools.  A  further  advance  is  required  in 
order  to  meet  the  scale  of  safety  critical  systems  as  typified  by  the  HOTOL  Spacecraft  (Horlsontal 
Take  Off  and  Landing) . 

The  issue  of  scale  is  a  special  one  as  it  leads  to  speculation  as  to  the  main  drivers  that  will 
lead  to  further  reductions  In  lifecycle  cost.  BAe*s  experience  with  mission  (as  opposed  to  safety) 
critical  software  on  SAP  has  led  us  to  conclude  that  further  significant  reductions  in  lifecycle 
cost  will  not  result  from  pursuing  Improvements  in  quality. 

The  SAFRA  approach*  which  concentrates  effort  on  the  earliest  stages  of  the  lifecycle  has  so 
reduced  the  scale  of  testing  required  that  the  latter  is  a  relatively  small  percentage  of  the 
overall  lifecycle  coses.  If  we  seek  an  order  of  magnitude  improvement  in  overall  productivity* 
this  must  come  from  physically  reducing  the  scale  of  the  implementation  task.  This  will  only 
emerge  through  large  scale  re-use  of  software,  either  by  employing  software  components  or 
specialised  high  level  languages. 

The  other  major  driver  on  future  software  engineering  requirements  lies  in  the  nature  of  avionic 
systems  themselves.  Until  recently*  the  C3rplcal  airborne  system  was  largely  self  contained, 
reflecting  the  independent  nature  of  the  operational  requirement.  The  introduction  of  datalinks, 
airborne  comeuind  and  control  stations  and  the  concept  of  overall  battle  management  as  typified  by 
Figure  4*  is  likely  to  change  this  view.  This  broader  picture  will  effect  Che  nature  of  airborne 
system  requirements  In  two  ways: 

*  Systems  will  be  In  a  perpetual  state  of  evolution 

*  They  must  be  considered  and  developed  with  a  view  to  interfacing  with  a  wide  range  of 
other  systems. 

This  change  in  the  nature  of  systems  Is  likely  to  affect  the  basic  lifecycle  model  that  underlies 
current  implementations. 

The  typical  model  (as  shown  in  Figure  1)  is  popularly  known  as  the  "Waterfall"  and  has  each 
successive  phase  being  defined  In  terms  of  input*  output*  method  to  generate  the  output  and  the 
tools  used  to  support  Che  application  of  the  method  and  validation  of  the  output.  Iteration  takes 
place  between  adjacent  phases  and  the  whole  lifecycle  can  be  repeated  to  develop  successive 
releases  of  software  over  the  life  of  a  system.  The  model*  however*  rests  on  the  assumption  that 
it  is  possible  to  define  the  requirements  completely  before  proceeding  with  Implementation  and 
design.  An  object  orientated  approach  to  systems  is  a  recognition  that  Che  completed  system  will 
only  be  arrived  at  through  a  succession  of  refinements. 

In  other  words*  the  lifecycle  is  geared  to  establishing  a  better  understanding  of  the  objective  of 
Che  system. 

With  such  an  approach  the  need  for  two  logically  parallel  lifecycles  emerges*  addressing 
prototyping  sod  system  development  respectively.  The  lifecycles  co-sxlst  and  are  served  by  methods 
and  tools  approprlats  to  thsm.  It  Is  likely*  however*  thet  although  there  Is  s  logical  separation 
of  activities  e^  phases  they  could  be  supported  by  e  physically  integrated  set  of  tools. 

The  approach  is  categorised  by  Figure  5.  The  detailed  nature  of  interaction  between  the  lifecycles 
is  a  function  of  the  type  of  prototyping  which  can  typically  fall  into  the  following  categories: 

*  Exploratory 

'  Experimental 

'  Performance 

*  Organiaetlonel 

*  Evolutionary 

The  predominant  concern  of  the  prototypli^  lifscycls  Is  to  understand  what  the  eventual  produce 
will  be*  This*  in  most  cases*  could  W  at  tha  expense  of  real  world  performance*  resilience  or 
integrity  except  where  the  nature  of  the  prototype  la  to  address  those  issues. 
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With  th«  aystn  davalopaant  llfaeycia  tha  iaportanca  of  producing  vail  englnaared  software  atlll 
appllaa  and  all  the  relevant  features  of  the  current  lifecycle  nodel  will  be  retained. 

The  challenge  of  both  scale  and  nature  will  be  net  by  a  new  generation  of  software  engineering  and 
an  equivalent  project  support  envlronnent  as  typified  In  Table  1.  Just  to  recap  for  a  nonent: 

*  The  first  generation  made  use  of  design  techniques  and  tools  over  the  whole  lifecycle  of 
software; 

*  The  second  generation  Is  destined  to  provide  a  connon  Infra-structure  that  supports  the 
tools  and  hence  a  full  software  design  and  nanagcnent  envlronnent. 

The  third  generation  will  extend  this  envlronnent  to  a  new  lifecycle  nodel  and  developnenC 
techniques  and  tools  to  Improve  productivity  by  several  factors.  One  of  the  key  enabling 
technologies  will  be  the  use  of  artificial  intelligence  and  hence  the  presence  of  a  knowledge  as 
well  as  a  database  at  the  heart  of  the  support  envlronnent. 

The  construction  of  such  an  envlronnent  Is  not  trivial  and  represents  a  considerable  advance  over 
current  progrsnnes  of  research  and  deveZopeent  but  is  likely  to  build  directly  on  their  results. 
It  la  not  a  task  that  can  be  undertaken  by  a  single  company  and  It  is  for  this  reason  that  five 
major  European  Aerospace  companies  have  proposed  that  they  collaborate  on  a  third  generation 
environment  entitled  AIMS  (Aerospace  Intelligent  Managesient  &  Development  Tool  for  Embedded 
Systems)  under  the  auspices  of  the  EUREKA  progrSMe.  The  prellninary  thoughts  on  AIMS  are  offered 
as  being  typical  of  a  third  generation  envlronnent. 

The  Scope  and  Nature  of  AIMS 

The  role  of  AIMS 


AIMS  will  provide  a  developnent  environment  for  aystens  or  subs^^tens  containing  embedded  software 
components.  It  nust  do  so  in  a  context  of  co-operative  work  between  teams  from  several  European 
countries  and  cover  all  stages  of  development  for  chose  parts  of  the  system  dependent  on  software 
costponencs. 

We  will  first  dlacuas  the  major  target  areas  of  system  development  that  AIMS  will  address  before 
describing  some  technical  aspects  of  the  AIMS  environment. 

Major  Targets 

*  Management  Support 

An  integrated  environment  for  co-operative  International  work  will  be  expected  to  provide 

extensive  facilities  for  project  managemenc.  Typlcslly  this  should  ineZude:- 

-  development  planning  with  day  to  day  assessment  of  achievement 

-  control  over  development  schedule  and  cost 

-  quality  control  and  management  of  Che  cost  of  design  evolution  and  modification 

-  configuration  managemenc 

*  Development  Organisation 

International  collaboration  causes  teams  of  developers  from  various  cultures  or 

backgrounds  to  work  together  over  many  years.  CoimBunlcation  and  flexibility  are  important 

In  Che  environment  they  will  be  using. 

-  Methodology-Independent  communication  tools  for  data  and  knowledge  exchange  will  be 
essential  so  that  teams  from  different  companies  may  continue  to  use  their  own  sets 
of  design  methods  and  tools.  They  must,  however*  be  able  to  communicate  freely  all 
kinds  of  design  data  In  an  homogenous  way. 

-  A  homogenous  environment  must  be  able  to  adapt  to  new  tools  and  the  design  methods 
they  support,  as  well  as  beli^  able  to  Integrate  advances  In  msn-machlne  interface  or 
workstation  technology. 

-  Acquisition*  storage  and  restitution  of  syscem-specif ic  and  engineering  knowledge  and 
experience  should  be  carried  out  at  automatically  as  possible. 

Support  for  systems  with  a  long  life  must  be  provl’ed.  including  the  storage  of 
knowledge  as  a  means  of  l^rovlng  overall  system  design  consistency  and  maintaining 
It  over  time. 

-  Design  methodologies  evolve  with  time  and  functions  like  documentation,  either  for 
the  user,  designer  or  configuration  manager,  must  be  supported  in  such  a  way,  as  to 
be  Independent  of  the  particular  design  methodology  used. 


Productivity 

AIMS  will  have  Co  support  the  development  of  large,  modular,  multi-technology 
applications,  with  multipla  tsams  that  can  use  different  sets  of  tools  sod  design  methods. 
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Ecducing  devtlopMBt  and  ■atotenaaea  coata  tnvolvaa: 

•>  raduclng  the  ouaber  of  Iteratlofta  froa  requlraaeata  to  laplaaeatatloa  and  delivery  of 
the  ayatea. 

-  providing  expert  aaaiatance  at  each  developaent  atage  for  efficient  tool  uaage, 
overall  conaiatency  checking  and  re^uae  of  previoua  developaenta . 

reducing  the  i^act  of  eorrectlofia  and  aodificatlona  and  Inproving  their  reliability. 
Thia  can  be  achieved  froa  preparation  in  the  conceptual  atagea,  preaervlng 
conaiatency  of  dealgn  optiona  over  ttae»  keeping  track  of  the  declalona  a^e  and  of 
the  reaaona  behind  then*  and  uaing  that  knowledge  for  inforaation  and  training  of 
neweoaera  to  the  project. 

*  Conaunlcetlon 

There  are  two  faeete  to  thia  aubject: 

-  The  *'aeaantic''  coaaunlcation  between  huaan  deciaion-aakera  and  Involving  elaborate 
nailing,  expert  (knowledge  baaed)  aaaiatance,  and  thorough  co-ordination  with  project 
nanageaent . 

-  The  exchange  of  technical  data  through  heterogeneoua  conputer  networka  and  different 
toola.  Syaten  deacriptlona  nuat  be  acceaaible  through  formal  meana  of  expreaaiont 
Independently  of  the  toola  uaed*  eo  that  they  can  be  tranaferred  fron  one  tool  to 
another  without  the  need  for  knowledge  of  a  apeclflc  tool  in  order  to  be  analyaed. 

There  la  of  courae  the  problem  of  confidentiality  with  induatrlal  data,  and  the 
acceaa  eondltiona  to  information  nuat  be  well  controlled. 

*  Expertlae 

Knowledge-baaed  aaaiatance  muat  be  provided  for  many  reaaonat 

-  Helping  apeciallata  to  co-operate  and  coamunicate  acroaa  distance  (European  projects) 
and  time  (product  updates).  A  knowledge-baaed  simulation  of  apeciallata  can  help 
designers  lAen  faced  with  technological  choices  or  assessing  the  Impllcatlona  of  the 
given  technology.  It  can  complement  and  accelerate  the  necessary  dialogue  between 
apeciallata,  chronology  of  decisions  and  how  they  were  reached.  Re-use  of  thia 
knowledge  as  expert  assistance  will  be  provided  for  long-term  design  maintenance;  it 
la  also  the  moat  flexible  meana  to  support  re-use  of  previous  developments. 

-  Domaln-apec if Ic  as  well  as  tool  apeclflc  knowledge  are  hard  for  individuals  to 
acquire.  If  it  la  available  in  the  development  tool  it  will  help  designers  to 
improve  their  cepebilley,  and  avoid  redundant  and  duplicated  origins. 

*  Simulation 

Over  the  lifecycle  of  such  cosq>lex  and  reliable  products  aa  aerospace  ayatema,  every  step 
muat  be  validated.  This  holds  especially  true  during  the  early  definition  stages,  when 
all  deciaiona  potentially  have  a  large  impact  on  development  coat  (feasibility)  and 
exploitation  cost  (quality). 

It  la  necessary  to  provide  the  design  with  tools  for  extensive  validation  and  evaluation 
of  these  decisions  with  high  financial  leverage  through  the  use  of  effective  almulatlon 
and  prototyping  toola. 

A  secondary  but  Important  practical  consequence  of  prototyping  Is  that  it  acta  aa  a  basis 
for  the  generation  of  teat  and  integration  procedures  for  later  stages  when  the  systems 
are  integrated. 

*  Tool  Support 

AIKS  la  expected  to  have  the  capacity  of  Integrating  and  supporting  new  CAD  cools  as  they 
become  available.  This  support  includes  data  format  converalrm  to  a  comnon  standard, 
documentation  and  expert  advisory  functions. 

AIMS  will  have  to  cope  with  very  sophisticated  tools  mixing  advanced  computing  techniques 
(networks,  data  and  knowledge  bases,  expert  systems,  graphic  man-machine  interface,  etc) 
in  very  heterogeneous  environments.  The  implementation  of  AIMS  muat  provide  aa  much 
portability  aa  possible. 

The  AIMS  Environment 

The  essence  of  the  Infrastructure  conaiata  of  a  database  surrounded  by  shells  coMitted  to 
configuration  control,  tool  interfaces  and  Mfl,  being  typical  of  currant  Integrated  Project  Support 
Environment  (IPSE'a)  as  described  above. 

In  moving  to  an  environment  chat  will  support  the  AIMS  concept  there  ia  a  growth  in  the  number  of 
functions  surrounding  the  databaac  and  the  added  requiremant  of  storing  and  acceaaing  a  knowledge 
base. 
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*  Proposed  Modal  for  aa  AIMS  EovlrooMBC 

Tha  aodal  la  llluatratad  la  Plgura  (6)  aad  can  be  aald  Co  cooaiac  of: 

->  A  data  and  kaovladga  aaaagamanc  karnal 
A  cool  aupporc  fraaavork 

-  Man-aachlna  iaCarfaca 

A  data  aad  knowladga  aaaagaaant  kemal 

An  objacc  orlaatatad  dace  aanagaaant  ayaCaa  to  atora  projact  rapraaancation  (working 
procotypaa  with  docuaentatlon  and  davelopaant  daca  and  lotarfaea  drivara  Co 
alaulacora  and  Caat  benches) .  Object  support  should  Include  aasaaga  sanding,  pattern 
Batching  and  data  ratrleval.  Whlla  project  aupport  requires  a  version  and  variant 
support  uclltcy. 

>  A  sat  of  knowledge  bases  with  chair  consultation  and  updating  facilities,  general 
inference  aachanian,  dialogue  support  and  archiving.  Aase  knowledge  bases  would 
cover: 

*  General  knowledge  (BatheBatlca.  physics) 

-  Donaln  specific  knowledge  (navigation  equlpaent,  cuatoner  needs) 

Design  eicperclse  (aathodology,  known  solutions) 

>  Product'Speclflc  expertise  (week-points  design  history) 

Moat  data  and  knowledge  la  of  course  proprietary  to  the  conpany  or  even  the  teas  using 
AIKS  so  Its  availability  to  other  users  (partners,  subcontractors)  «rlll  need  to  be 
carefully  controlled. 

*  A  tool  support  framework 

Tools  must  continue  to  be  Interfaced  to  the  kernel  and  to  one  another.  The  framework 
must  provide  a  homogeneous  envlroaent  for  the  tools  to  use  taking  Into  account  Che 
following: 

-  User  infomatlon  and  advice,  for  a  consistent  style  of  working  across  projects.  This 

Includes  oMChodological  help,  aupport  for  knowledge  baae  conaultstion  and  user  to 
user  communication.  It  must  not  be  forgotten  Chat  typical  system  development 

organisations  will  ba  vary  "dlsCrlbuced**  ao,  aa  mailing  Is  s  very  "smart" 
application,  It  must  be  complemented  by  expert  system  consultation  to  speed  things 
up. 

-  Support  for  all  kinds  of  design  tools  with  a  convenient  Interface  structure  to  the 

kernel  Co  ocher  tools  and  to  the  user.  Aa  outer  layer  would  provide  user  guidance 

for  proper  use  of  Che  cools. 

-  Special  support  for  project  managerCs)  and  lifecycle  issuea  such  as  quality 

management  and  configuration  control. 

Special  support  for  Root/Target  testing  particularly  at  system  Integration,  including 
provision  for  fault  diagnosis. 

AIKS  Is  about  to  enter  Che  d^fiaition  phase  at  the  beginning  of  a  five  year  progratme  of 
davalopment  and  Implemantatlon.  The  collaborating  partnara  Include: 

*  Aerospatiale 

*  Aaricalls 

*  British  Aerospacs 

*  CASA 

*  MBB 

Software  houaas  in  each  Individual  country  are  also  likely  to  ba  Isvolvad  where  apaclallst 
experciee  Is  required. 

It  is  hoped  Chat  as  well  as  providing  an  advanced  environment  to  meet  Che  needa  of  Che  partners, 
AIMS  will  also  provide  soma  of  the  framework  for  European  standardisation  on  future  Software 
Engineering  isauaa. 
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. . .  A  First  Generation  of  Software  Engineering 
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Fig  5.  Third  Generation:  The  Solution 

A  New  Lifecycle  Model 


BtnnsM 

*mosmce 


Fig6.  Third  Generation:  The  Solution 

ax  we»  AIMS  Environment 


1 


22-1 


SOFTWARE  READINESS  PLANNING 


Jack  Cooper 

Anchor  Software  Hanagement 
5109  Leesburg  Pike,  Suite  214 
Falls  Church,  VA  22041 


Summary 

This  paper  presents  a  method  wherein  the  capability  to  support  and  make  changes  to 
avionics  system  software  during  the  readiness  phase  of  Its  life  cycle  can  be  guaranteed. 

In  recognizing  that  the  supportabi 1 1 ty  of  software  Is  completely  determined  during  Its 
development,  the  method  centers  around  pre- devel opment  planning,  decisions  and  actions 
on  the  part  of  the  avionics  system's  acquisition  manager.  Discussed  are  the  software 
engineering  considerations  that  must  be  Included  in  the  contract  to  facilitate  the 
future  supportabi 1 i ty  of  the  software.  That  Is  followed  by  a  description  of  contractual 
requirements  to  be  placed  on  the  software  support  environment  used  to  develop  the  avionics 
software  to  ensure  the  life  cycle  supportabi 1 1 ty  of  the  target  avionics  software.  Two 
tools,  a  management  Plan  and  a  contracting  Standard,  that  support  the  method  for  ensuring 
software  supportabi 1 1 ty  are  described.  The  Plan  provides  a  vehicle  for  Joint,  customer 
and  contractor,  management  of  the  developmental  software  support  environment.  The  Standard 
provides  the  contractual  life  cycle  supportabi 1 1 ty  requirements. 


I.  Introduction 

The  magnitude  of  a11  operational  and  support  software  for  an  avionics  system  could 
amount  to  millions  of  lines  of  code.  The  development  and  life  cycle  support  of  this 
quantity  of  software  is  a  major  project  consi deratl on .  Consequently,  it  is  very  impor¬ 
tant  that  planning  for  all  aspects  of  these  efforts  be  completed  before  software  devel¬ 
opment  begins.  A  Software  Life  Cycle  Management  Plan  is  an  excel  lent  vehi c 1 e  for  this 
planning.  Such  a  document  should  he  completed  prior  to  entering  Into  a  contract  or 
Internal  task  agreement.  A  Software  Life  Cycle  Management  Plan  will  preclude  any  of  the 
Important  aspects  of  software  development  and  support  from  becoming  a  fait  accompli. 

Since  planning  for  a  software  development  project  has  been  widely  discussed  else¬ 
where,  this  paper  focuses  on  planning  Issues  related  to  supporting  software  during  the 
readiness  phase  of  its  life  cycle.  It  is  paramount  that  software  life  cycle  readiness 
Issues  be  provided  for  In  the  Initial  software  development  contract  or  task  agreement. 
Current  estimates  are  that  something  In  excess  of  75%  of  the  total  cost  of  the  software 
Is  expended  during  Its  readiness  phase.  Since  the  requirements  for  developing  and  sup¬ 
porting  software  are  not  always  the  same,  all  acquisition  tradeoffs  should  be  weighted 
3-to-l  in  favor  of  supportabi 1 i ty .  For  example,  a  decision  to  use  assembly  language 
during  development  In  the  Interest  of  some  form  of  efficiency  must  also  consider  the 
cost  of  supporting  the  assembly  language  code  over  the  ent1*‘e  readiness  phase  of  the 
system' s  life  eye  1 e . 


II.  Software  Readiness  Planning 

During  the  acquisition  and  development  of  avionics  software,  we  are  Interested  in 
the  following  readiness  issues  and  must  ensure  that  they  are  included  in  the  Software 
Life  Cycle  Management  Plan  or  its  equivalent  prior  to  contracting  or  tasking: 

*  Sufficiency  and  quality  of  the  documentation 

*  The  development  methodology  to  be  used 

*  The  engineering  standards  to  be  used 

*  The  programming  language  to  be  used 

*  The  system  test  requirements 

*  Availability  of  system  resources  for  making  changes 

*  Sufficiency  and  adequacy  of  the  support  environment 

*  System  transition  planning 

Documentation  is  clearly  the  most  critical  requirement  in  supporting  large  amounts 
of  software.  During  a  system's  readiness  phase,  software  changes  will  be  required  long 
after  the  original  developer  1$  no  longer  available.  To  make  a  successful  change  to  an 
item  of  software,  the  engineer  must  know  what  that  item  was  required  to  do,  how  It  fits 
into  the  rest  of  the  system,  and  how  it  actually  works.  He  must  then  determine  how  the 
item  must  be  changed,  how  to  Integrate  the  new  code  Into  the  existing  software,  and  what 
changes  must  be  made  to  other  Items  of  software  so  the  the  new  one  will  Interface  prop¬ 
erly.  Documentation  is  the  only  tool  an  engineer  has  available  to  decipher  all  of  this 
Information.  Program  Design  Languages  (POL),  flow  charts,  and  program  listings  either 
do  not  contain  the  necessary  information  or  It  Is  too  Impractical  to  dig  out  the  infor¬ 
mation.  For  example,  software  requirements  and  common  data  base  definition  usually  are 
not  found  In  those  forms  of  documentation.  High  level  design  and  interface  definitions 
are  extremely  difficult  to  extract.  POLs,  flow  charts,  and  listings  are  best  used  in 
the  area  of  understanding  the  as-bu11t  Information. 
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A  full  range  of  docunenta  are  needed.  Docunents  Bust  be  available  during  the 
readiness  phase  that  contain  accurate,  coaplete  definition  of  the  software's  regulre- 
fflents,  design.  Interfaces,  data  bases,  and  the  as-built  description.  In  order  to  be 
able  to  continue  to  test  the  systea,  as  well  as  test  the  subsequent  changes  to  the 
systea,  docuaents  containing  the  testing  requlreaents  and  detailed  test  procedures  aust 
be  available.  The  bit  pattern  of  any  firaware  In  the  systea  aust  be  docuaented  and, 
naturally,  operator  and  user  Instructions  too.  It  Is  laperative  that  a11  of  these 
required  docuaents  be  produced  concurrently  with  the  software,  since  producing  thea  by 
reverse  engineering  during  the  readiness  phase  Is  considerably  aore  expensive  than  ob¬ 
taining  them  under  the  original  software  developaent  contract. 

The  aethodology  used  to  develop  software  has  considerable  lapact  on  the  supportabi 1 1 ty 
of  software.  A  highly  aodular  structure  developed  top  down  using  the  ’Inforaatlon  hiding' 
and  ‘structured  prograaaing*  aethodol ogl es  Is  auch  aore  aodiflable  and  changeable.  The 
methods  employed  also  Impact  other  supportabi 1 1 ty  requirements  such  as  transportability 
and  reuseablllty.  These  are  Important  considerations  that  must  be  Included  In  project 
planning  activities. 

When  deciding  on  the  engineering  standards  to  be  used  during  software  developaent, 
supportabi 1 1 ty  again  must  be  considered.  As  discussed  above,  software  Is  supported  much 
more  easily  If  It  Is  developed  using  a  high  level  language,  such  as  Ada,  rather  than  an 
assembly  language.  The  quality  assurance  procedures  must  be  oriented  toward  assuring 
satisfaction  of  readiness  requirements.  Often  overlooked,  but  an  extremely  valuable 
supportabll 1 ty  tool.  Is  the  history  of  the  software.  Items  such  as  Unit  Development 
folders  (UQFI,  software  trouble  reports,  software  change  control  documents,  and  test 
results  that  are  a  part  of  the  software  developaent  process  provide  very  useful  histori¬ 
cal  Information  to  a  software  engineer  Involved  In  the  software  change  process. 

Testing  during  software  developaent  Impacts  Its  supportabi 1 1 ty  In  several  ways. 
Obviously,  the  quality  of  the  test  effort  greatly  Influences  the  resulting  reliability 
of  the  systea.  Beyond  that,  keep  In  mind  that  the  software  needs  to  be  tested  many 
times  during  Its  much  longer  readiness  phase.  After  each  change  to  the  software,  the 
change  Itself  must  be  tested  and  a  certain  amount  of  systea  regression  testing  performed. 
Consequently,  all  of  the  test  specifications,  procedures,  tools,  environments,  and  reports 
(history)  that  were  used  In  developing  the  software  are  also  needed  to  support  the  system 
for  the  remainder  of  Its  life  cycle.  Planning  oust  Include  provisions  for  providing  these 
resources  to  the  life  cycle  software  support  activity  sufficiently  In  advance  of  system 
del  Ivery. 

Inherent  In  the  concept  of  life  cycle  readiness  of  software  Is  the  making  of  changes 
to  the  software.  These  changes  range  from  correcting  minor  errors  to  Implementing  major 
system  enhancements.  The  laplementatlon  of  a  change  usually  consumes  soae  amount  of  the 
memory,  execution  time,  and/or  I/O  resources.  Thus,  these  resources  must  be  available 
In  the  target  avionics  system  In  order  to  effect  the  change.  Adding  these  resources  to 
a  avionics  system  during  Its  readiness  phase  may  not  be  possible  because  of  space,  weight, 
power,  cooling,  or  Interference  limitations.  Planning  before  system  development  Is 
necessary  to  Insure  the  availability  of  these  resources  during  the  readiness  phase  of  the 
life  cycle.  Many  of  the  U.S.  Department  of  Defense  contracts  for  development  of  avionics 
systems  are  requiring  a  reserve  In  the  availability  of  these  computer  system  resources  of 
50t  at  the  time  of  delivery  to  the  Government. 

Planning  for  the  life  cycle  software  support  environment  and  the  orderly  transition 
of  software  support  from  the  developer  to  the  life  cycle  support  activity  are  such  Im¬ 
portant  considerations  that  each  will  be  discussed  In  subsequent  sections. 

III.  Software  Support  Environment  Planning 

There  are  two  software  support  environments  to  be  considered.  The  one  used  during 
original  development  of  the  software.  Developmental  Software  Support  Environment  (DSSE); 
and  the  one  to  be  used  for  the  remainder  of  the  software's  life  cycle.  Life  Cycle  Soft¬ 
ware  Support  Environment  (LCSSE).  Both  must  be  planned  In  detail  prior  to  the  commence¬ 
ment  of  any  project  activities,  especially  contracting.  In  order  to  transfer  success¬ 
fully  an  avionics  system  from  Its  developer  to  Its  life  cycle  support  activity,  these 
two  environments  must  be  compatible  and  the  LCSSE  must  have  the  requisite  capability. 

There  are  other  Important  planning  Issues  to  be  addressed  before  discussing  the  specif¬ 
ics  of  LCSSE  planning. 

Foremost  Is  the  true  total  cost  of  software  development.  This  cost  Includes,  not 
only  the  cost  of  developing  the  software,  but  also  the  cost  of  establishing  the  life 
cycle  software  support  capability.  A  compiler  provides  a  good  example.  If  the  software 
developer  uses  a  compiler  that  Is  not  a  component  of  the  L.SSE,  one  must  be  added.  If 
the  customer  Is  forced  to  purchase  the  compiler.  Its  cost  aust  be  added  to  the  cost  of 
software  development  and  aust  be  Included  In  the  project's  budgeting  activities.  This 
situation  Is  even  more  Important  In  the  case  of  a  competitively  awarded  contract  for  the 
software  developaent.  The  cost  of  establishing  the  life  cycle  software  support  capabil¬ 
ity  should  be  taken  Into  account  when  evaluating  the  proposals.  What  appears  on  the 
surface  to  be  the  most  cost  effective  proposal  may  turn  out  to  be  the  most  expensive  In 
the  long  run  when  the  support  software  costs  are  Included. 
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Related  to  the  true  cost  of  software  development  are  the  costs  associated  with  data 
rights,  when  proprietary  products  are  used.  In  a  cost-plus  type  contract,  who  pays  for 
the  cost  of  using  the  proprietary  product  during  software  development?  Is  the  pro¬ 
prietary  product  required  In  order  to  perform  life  cycle  software  support?  If  so.  how 
much  does  the  right  to  use  the  product  In  the  LCSSE  cost?  Who  supports  the  proprietary 
product  If  Its  owner  goes  out  of  business  or  decides  to  stop  supporting  the  product? 
These  are  just  some  of  the  questions  that  must  be  resolved  when  an  Item  Is  used  during 
software  development  that  has  restrictions  on  Its  use.  These  answers  are  needed  before 
the  Item  Is  used  and  the  customer  has  no  choice  but  to  pay  whatever  the  cost. 

To  give  visibility  to  the  cost  of  software  support  items  and  their  data  rights  and 
to  assist  In  assuring  supportabll 1 ty  of  the  system,  the  development  of  a  OSSE  Plan  Is 
highly  recommended.  Ideally,  the  software  developer  prepares  the  DSSE  Plan  and  then 
obtains  the  approval  of  the  customer.  Once  both  parties  have  agreed  to  the  Plan,  all 
subsequent  changes  and  deviations  to  the  Plan  then  require  concurrence  by  both  parties. 
The  remaining  paragraphs  of  this  Section  discuss  the  type  of  Information  that  1$  typi¬ 
cally  contained  In  a  OSSE  Plan. 

A.  Introduction  -  A  top  level  executive  summary  of  the  contents  of  the  OSSE  Plan. 
It  should  contain  a  brief  overview  of  the  DSSE,  LCSSE,  and  the  target  computer  system. 
This  overview  Includes  the  relationships  among  these  three  systems.  The  differences 
between  the  OSSE  and  the  LCSSE  are  to  be  highlighted.  Requirements  for  the  customer  to 
provide  any  resources  to  the  developer  for  Inclusion  In  the  DSSE  are  summarized  herein. 
It  is  Imperative  that  a  general  discussion  of  limited  or  restricted  rights,  licensing 
agreements,  or  any  other  legal  limitations  Involved  be  presented  at  this  point.  This 
Section  also  provides  a  convenient  opportunity  to  discuss  any  Involvement  by  sub¬ 
contractors  and  vendors. 

8.  Applicable  Documents  -  The  DSSE  Plan  Is  to  Include  a  reference  to  all  documen¬ 
tation  that  is  related  to  the  DSSE  or  the  supportabi 1 1 ty  of  the  target  system. 

C.  DSSE  Description  -  A  detailed  description  of  the  DSSE.  The  Internal  organiza¬ 
tion  of  the  DSSE  and  Its  Interfaces  with  all  aspects  of  the  software  development  process 
Is  to  be  Included.  The  use  of  graphics  to  show  work  and  data  flows  are  very  helpful  In 
depicting  the  various  relationships.  Topics  to  be  addressed  as  subsections  are: 

Host  System  Description  -  The  host  computer.  Its  operating  system,  and  periph¬ 
eral  devices. 


Central  Library  -  The  organization  of  the  central  library,  its  file  structure, 
data  base  management  system,  and  interfaces. 

Tool  Set  -  An  Itemization  and  description  of  all  tools  available  In  the  DSSE. 

User/System  Interface  -  Operating  features  of  the  DSSE  and  Instructions  for 
accessing  and  using  the  system. 

OSSE  Relationship  to  Target  System  -  A  description  of  all  items  In  the  DSSE  as 
to  how  they  relate  to  the  target  system  under  development. 

D.  OSSE  Relationship  to  the  LCSSE  -  A  detailed  discussion  of  the  relationships 
between  the  two  environments.  Topics  that  must  be  addressed  as  subsections  are: 

DSSE/LCSSE  differences  -  The  detailed  differences  between  the  DSSE  and  the 
LCSSE.  It  Is  critical  that  the  customer  fully  understand  how  these  differences  affect 
the  compatibility  of  the  two  environments  and  what  effect  that  has  on  the  life  cycle 
supportabi 1 1 ty  of  the  target  system  under  development. 

Items  Unique  to  the  Target  System  -  A  listing  of  all  items  to  be  used  In  the 
DSSE  that  are  unique  to  the  target  system  to  be  developed. 

Items  Recommended  to  be  Added  to  the  LCSSE  -  This  Subsection  provides  the 
developer  an  opportunity  to  propose  the  use  of  DSSE  Items  that  could  be  added  to  the 
LCSSE  to  enrich  Its  capabilities. 

Items  to  be  Used  Only  In  the  DSSE  -  An  Itemization  of  those  DSSE  items  that  are 
not  recommended  for  addition  to  the  LCSSE. 


E.  DSSE  Implementation  -  The  developer's  planned  management  procedures  and  Imple¬ 
mentation  of  the  DSSE.  Also  to  be  Included  Is  information  describing  the  DSSE  Plan's 
relationship  to  all  other  project  Plans  such  as  Software  Development,  Quality  Assurance, 
and  Configuration  Management.  Topics  that  must  be  addressed  as  subsections  are: 

Items  to  be  Furnished  by  the  Customer  -  Those  DSSE  items  that  are  required  to 
be  furnished  by  the  customer. 


Items  that  are  Commercially  Available  -  All  DSSE  Items  planned  for  use  that  are 
available  commercially.  If  the  use  of  any  of  these  Items  Involves  proprietary  consid¬ 
erations  such  as  limited  or  restricted  data  rights  or  licenses,  It  Is  Imperative  that 
the  customer  be  aware  of  that  fact  and  consider  the  associated  costs  that  he  will  Incur 
In  order  to  perform  life  cycle  support  of  the  target  system. 


22-4 


Itens  that  are  Privately  Developed  -  All  OSSE  Itees  planned  for  use  that  are 
not  available  coaaierclally  but  are  available  from  private  sources.  If  the  use  of  any  of 
these  Iteas  Involves  proprietary  considerations  such  as  Halted  or  restricted  data 
rights  or  licenses.  It  Is  laperative  that  the  custoaer  be  aware  of  that  fact  and  con¬ 
sider  the  associated  costs  that  he  will  Incur  In  order  to  perfora  life  cycle  support  of 
the  target  systea. 

Iteas  that  are  to  be  Newly  Developed  -  Those  DSSE  Iteas  that  do  not  exist  at 
the  tiae  the  software  developaent  project  Is  begun  but  must  be  developed  concurrently  In 
order  to  support  the  developaent  effort. 

P.  DSSE  Operation  -  A  description  of  the  procedures  and  controls  to  be  used  In 
managing  the  utilization  of  the  environaent.  Also  Included  must  be  a  discussion  of  how 
all  subsequent  changes  to  the  DSSE  will  be  aanaged. 

G.  Target  Systea  Supportabll 1 ty  -  The  ability  to  operate  and  support  the  target 
system  Is,  In  essence,  the  bottom  line  of  the  software  developaent  process.  This  Sec¬ 
tion  addresses  those  Issues  that  determine  whether  or  not  the  target  system  can  be 
supported.  Topics  that  must  be  addressed  as  subsections  are: 

Addition  of  new  Iteas  to  the  LCSSE  -  During  developaent  of  the  target  system. 
Items  of  support  software  and  perhaps  hardware  can  be  expected  to  be  used  that  are  not 
currently  a  part  of  the  LCSSE.  It  may  be  necessary  that  some  of  these  Items  be  Incorpo¬ 
rated  In  the  LCSSE  In  order  to  perform  life  cycle  software  support  of  the  target  system. 
There  are  two  aspects  to  be  considered.  First,  those  Items  must  be  obtained  for  Inclusion 
In  the  LCSSE.  Secondly,  those  Items  must  be  operable  In  the  LCSSE.  Both  subjects  must 
be  taken  Into  account  In  the  planning. 

Execution  Compatibility  -  It  Is  very  Important  that  all  software  newly  Inte¬ 
grated  Into  the  LCSSE  execute  properly  In  Its  new  environment. 

Operation  Compatibility  -  It  Is  also  Important  to  ensure  that  all  operations  or 
functions  that  were  available  during  development  are  also  available  the  people  who  will 
be  maintaining  and  supporting  the  systea  over  the  remainder  of  its  life  cycle. 

Compatibility  of  Results  -  In  order  to  support  the  software  of  new  system  It  Is 
necessary  that  the  newly  delivered  software  produce  the  same  results  when  executed  In 
the  LCSSE  that  It  did  when  It  was  developed  and  tested  In  the  DSSE. 

Compatibility  Warranty  -  The  software  developer  must  be  held  responsible  for 
ensuring  that  nothing  Is  done  during  development  that  has  an  adverse  effect  on  the  new 
software’s  proper  execution,  thus  Its  supportabf 1 1 ty ,  after  delivery.  It  Is  not  unrea¬ 
sonable  to  ask  the  developer  to  Identify  to  the  customer  how  he  Intends  to  demonstrate 
that  the  compatibility  needed  for  life  cycle  supportabl 1 1 ty  has  been  achieved.  Address¬ 
ing  these  compatibility  Issues  In  the  DSSE  Plan  not  only  serves  to  Insure  that  these 
Important  consideration  are  not  overlooked,  but  It  provides  the  vehicle  for  both  the 
developer  and  his  customer  to  Jointly  agree  on  how  this  compatibility  will  be  demon¬ 
strated  . 


IV.  Software  Transition  Planning 

The  next  area  that  must  be  addressed  In  software  readiness  planning  is  the  orderly 
transition  of  all  software  to  be  delivered  from  custody  of  the  developer  to  custody  of 
the  customer.  The  transition  Includes  all  deliverables  of  the  software  developaent 
effort,  the  documentation  and  support  tools  as  well  as  the  computer  programs.  It  Is 
Important  that  the  systea  turn-over  occurs  on  the  prescribed  date.  To  leave  software 
support  with  the  developer  normally  represents  an  unprograamed  cost  growth  or  a  delay  In 
operational  capability.  A  smooth,  effective  transition  Is  one  which  results  In  minimal 
disruption  of  system  support. 

Critical  to  a  smooth  transition  Is  that  the  customer  be  completely  prepared  to 
receive  the  new  deliverables  without  a  disruption  In  support  to  the  new  system.  The 
customer  must  have  adequate  hardware  and  software  facilities  in  place,  and  must  have 
adequate  personnel  on  board  trained  In  the  operation  and  maintenance  of  the  new  system. 
This  could  require  additional  LCSSE  host  computer  system  resources  to  be  Installed.  The 
new  system  may  require  new  support  software  to  be  added  to  the  LCSSE  such  as  simulators, 
to  be  available  for  testing  of  changes  to  the  operational  software.  Various  support 
personnel  may  need  to  attend  specialized  training  courses.  The  LCSSE  operating  procedures 
may  need  to  be  revised.  New  facilities  may  need  to  be  constructed  or  existing  ones 
modified.  To  have  available  these  types  of  capabilities  at  the  time  of  scheduled  system 
turn-over  may  necessitate  long  lead-tlae  software  developments,  hardware  acquisitions, 
and  training,  all  of  which  require  advance  planning. 

The  transition  plan  should  Include  the  following  considerations: 

A.  Responsibilities  for  accoapl 1 shaent  of  significant  transition  activities  need 
to  be  assigned  to  specific  personnel. 
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B.  Additional  hardware  required  for  Inclusion  In  the  LCSSE  eust  be  Iteelzed. 
Slallarly,  the  additional  support  software  required  for  Inclusion  In  the  LCSSE  oust  also 
be  1  teal  zed. 

C.  Additional  aanpower,  nuabers  and  skills,  required  for  support  of  the  new  systea 
along  with  all  related  training  requireaents  need  to  be  Identified. 

D.  The  logistics  Involved  In  the  physical  transfer  of  the  new  systea  froa  the 
contractor's  facility  to  the  custoaer's  facility  needs  to  be  prograaaed. 

E.  Contracting  for  construction  or  facility  aodificatlon  requires  prograaming 
(funding  too). 

This  aandatory  planning  aay  be  contained  In  a  separate  transition  plan  or  could  be 
Included  In  the  OSSE  Plan.  As  noted  In  an  earlier  paragraph.  It  can  be  seen  that  the 
central  focus  of  the  transition  plan  should  be  the  schedule  of  allestones  and  events 
leading  up  to  the  turn-over.  The  transition's  critical  path  should  be  Identified, 
paying  particular  attention  to  the  lead-tlaes  associated  with  the  acconpl 1 shaent  of  each 
1  tea. 


V.  Contracting  For  Software  Readiness 

Over  the  past  decade  there  has  been  a  draaatic  Increase  In  the  acquisition  and 
deployment  of  digital  avionics  systens.  Although  some  coaaonallty  has  been  achieved, 
the  diversity  of  requireaents  has  resulted  In  a  large  nuaber  of  unique  coaputer  systems. 
Each  unique  computer  system  brings  with  It  Its  own  set  of  life  cycle  software  readiness 
requirements.  The  complexity  of  these  digital  avionics  systems  requires  the  life  cycle 
software  support  activity  to  provide  a  full  range  of  engineering  services.  Including  the 
Integration  of  the  operational  software  with  the  other  elements  of  the  avionics  system. 

When  several  avionics  systems  are  assigned  to  a  single  life  cycle  software  support 
activity  to  gain  the  economies  of  centralization,  the  software  support  environment  must 
support  all  common  functional  requirements  and  capabilities,  as  well  as  the  unique 
support  requirements  of  each  system.  This  workload  demands  an  extremely  large  software 
support  environment  base  to  maintain  and  enhance  all  these  systems.  Compounding  the 
situation  Is  the  fact  that  these  systems  are  being  developed  by  many  different  contrac¬ 
tors. 


A  standard  subset  of  each  life  cycle  software  support  environment  needs  to  be 
Identified  and  software  development  contractors  should  be  tasked  to  be  compatible  with 
this  portion  of  the  life  cycle  software  support  environment  that  exists  at  the  designated 
life  cycle  software  support  activity.  As  each  environment  matures,  the  standard  environ¬ 
ment  Is  expected  to  grow,  and  thus  Increases  the  requirement  for  standardized  and  trans¬ 
portable  support  software.  The  life  cycle  software  support  activities  must  Identify 
their  support  requirements  and  uniformly  task  the  software  development  contractors  to 
be  compatible  with  their  environment  before  the  new  software  Is  delivered. 

Acquisition  managers,  when  contracting  for  systems  that  Include  the  development  of 
software,  are  often  unfamiliar  with  the  requirements  for  life  cycle  software  readiness. 
They  are  usually  unaware  of  the  various  components  of  the  software  support  environment 
needed  In  order  to  perform  the  life  cycle  software  support  functions  during  the  readi¬ 
ness  phase  of  the  system's  life. 

For  the  acquisition  manager,  use  of  a  contracting  standard  Is  the  most  effective 
way  to  solve  many  of  the  software  readiness  problems.  Such  a  standard  provides  a  common 
requirement  for  all  contracts  that  contain  software  development  and  provides  a  vehicle 
to  ensure  compatibility  with  a  designated  life  cycle  software  support  environment.  It 
Is  also  a  tool  for  program  managers  to  use  In  writing  their  contracts  to  make  sure  that 
this  Important  area  receives  proper  contractual  attention.  It  also  allows  the  life 
cycle  software  support  activities  to  Identify,  prior  to  selection  of  the  software  devel¬ 
opment  contractor,  their  particular  requirements  and  to  task  the  software  development 
contractor  to  be  compatible  with  the  existing  standardized  life  cycle  software  support 
environment. 

In  answer  to  the  need  for  such  a  contacting  standard,  the  U.S.  Army  has  developed 
DOD-STO-1467  (AR),  "Software  Support  Environment”,  and  an  associated  set  of  support 
software  documentation  requirements  to  address  fully  the  requirements  for  life  cycle 
software  readiness.  This  Standard  Is  Intended  to  be  a  contractual  companion  to 
D00-STD-1679A,  "Software  Development"  and  DOO-STD-2167,  "Defense  System  Software  Devel¬ 
opment".  DOO-STD-1467  Is  to  developing  and  acquiring  support  software  what  these  other 
two  Standards  are  to  developing  and  acquiring  operational  softwaie.  DOD-STD-1467  ensures 
that  all  Issues  of  software  readiness  are  properly  addressed  In  contracted  software 
development  efforts,  and  It  provides  the  mechanisms  to  ensure  the  existence  of  a  com¬ 
plete  life  cycle  software  support  capability  for  contractually  deliverable  software  upon 
Its  entry  Into  the  operational  Inventory.  Although  DOD-STD-1467  was  developed  for  the 
Army,  It  provides  the  basis  and  structure  for  any  organization  to  ensure  the  life  cycle 
supportabi 1 1 ty  of  their  software. 
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The  Standard  Is  designed  to  recognize  the  needs  and  constraints  of  existing  life 
cycle  software  support  activities  and,  at  the  saae  tioe.  to  allow  the  contractor  flexi¬ 
bility  to  develop  software  and  aanage  the  contract  In  accordance  with  his  best  judgeaent 
and  practices.  Accordingly,  DOD-STD-IAST  does  not  dictate  the  approach  to  be  used  by 
the  contractor. 

The  contracting  activity  noraally  Identifies,  In  the  request  for  proposal,  the 
designated  life  cycle  software  support  activity  and  any  of  Its  Iteas  that  are  designated 
for  use  by  the  contractor.  Subject  to  the  constraints  laposed  by  the  contracting  activ¬ 
ity,  the  contractor  aay  propose  to  use  the  existing  resources  of  the  life  cycle  software 
support  activity,  to  use  the  contractor's  own  resources  (either  existing  or  to  be  devel¬ 
oped),  or  to  select  froa  a  wide  range  of  options  in  between.  The  contractor  then  Iden¬ 
tifies  his  selected  approach  In  the  proposal  for  the  contracted  software  effort.  The 
contractor's  approach  Is  considered  during  source  selection. 

There  Is  a  5-step  approach  to  using  D0D-STD-M67  In  a  contract:  1)  estab)  1  shaent 
of  a  jointly  approved  DSSE  Plan;  2)  lap) eaentatl on  of  that  Plan  during  software  devel- 
opaent;  3)  saooth  transition  of  all  contractually  deliverable  software  to  the  LCSSE;  4) 
demonstrated  supportabfl 1 ty  of  all  contractually  deliverable  software  In  the  LCSSE 
Itself;  and  5)  ensuring  that  the  new  Iteas  of  software  operate  correctly  In  the  LCSSE. 

Inadequate  provisions  for  protecting  the  U.S.  Amy's  rights  to  technical  data  and 
computer  software  necessary  for  operation  and  support  of  Its  weapon  systeas  historically 
have  been  responsible  for  decreased  operational  and  support  capabilities.  In  some 
cases,  considerable  additional  expense  was  necessary  to  procure  or  develop  the  Inforna- 
tlon  required  by  the  Amy  to  sustain  the  operation  and  support  of  Its  operational  sys¬ 
tems.  As  a  general  rule,  the  contract  guarantees  the  Amy  unlimited  rights  to  a1 1 
technical  data  and  software  specified  In  the  contract's  Delivery  Schedule.  However,  the 
acceptance  of  software  with  restricted  rights  nay  be  necessary  for  the  Amy  to  obtain 
rights  to  use  contractor-owned  or  state-of-the-art  software  that  Improve  the  operation 
and  efficiency  of  the  life  cycle  software  support  activities.  In  addition,  to  maintain 
the  currency  of  the  software  support  organizations.  It  may  be  In  the  best  Interests  of 
the  contracting  activity  to  accept  limits  and  restrictions  on  support  software.  This 
acceptance  should  encourage  the  use  of  new  or  Improved  software  support  Items  by  con¬ 
tractors  and  ensure  the  accessibility  of  these  Items  to  the  life  cycle  software  support 
activities. 

OOD-STO-1467  defines  the  responsibilities  of  the  contractor  to  obtain  approval  to 
deliver  software  with  restrictions.  This  prior  approval  encompasses  all  software  or 
documentation  required  to  operate  and  support  the  contractually  deliverable  software 
over  the  readiness  phase  of  Its  life  cycle.  The  specifics  of  types  of  software  and 
their  limitations  are  addressed  In  the  contractor's  proposal,  negotiated  and  resolved 
during  proposal  evaluation  and  contract  negotiation,  and  Included  In  the  resulting  con¬ 
tract. 

An  Ada  Programming  Support  Environment  (APSE)  Is  a  good  example  of  the  type  of  life 
cycle  support  environment  envisioned  by  OOD-STD-1467.  Contracting  activities  may  desig¬ 
nate  or  furnish  the  APSE  to  be  Included  In  the  contractor's  DSSE.  The  Standard  supports 
the  APSE  concept  of  providing  the  Identification  and  adoption  of  new  tools  for  a  selec¬ 
tive  (LCSSE)  growth;  and  allows  the  contractor  freedom  to  Incorporate  new  (APSE)  tools 
In  his  DSSE.  Since  the  DSSE  Is  required  to  be  compatible  with  the  LCSSE  APSE,  the  aug¬ 
mented  supportabi 1 1 ty  of  the  system  by  APSE  tools  can  be  operationally  verified  and 
warranted.  This  allows  for  continued  growth  and  Improvement  of  APSE  capabilities. 

In  summary,  the  use  of  OOO-STD-1467  forces  as  many  decisions  as  possible  Into  the 
proposal  and  subsequent  contract;  requires  prior  customer  approval  of  support  software 
used  to  develop  the  operational  software;  requires  the  contractor  to  ensure  life  cycle 
supportabi 1 1 ty  of  operational  software;  and  minimizes  any  additional  cost  growth  to  the 
actual  software  development  contract.  Also,  the  use  of  DOD-STD-1467  minimizes  any 
possible  conflicts  regarding  the  'rights  In  data'  problem  and  It  provides  a  'measuring 
tool"  for  determining  the  life  cycle  readiness  of  the  operational  software. 

VI.  Summary 

Planning  for  software  supportabi 1 1 ty  during  the  readiness  phase  of  a  digital 
avionics  system's  life  cycle  has  often  been  neglected.  Consuming  over  75*  of  the  total 
cost  of  the  system.  It  Is  very  Important  that  life  cycle  software  supportabi 1 1 ty  be  as 
efficient  and  cost-effective  as  possible.  The  supportabi 1 1 ty  of  software  Is  completely 
determined  during  It  development.  Consequently,  planning  for  supportabi 1 1 ty  must  begin 
prior  to  contracting  for  software  development.  The  DSSE  Plan  provides  a  good,  conven¬ 
ient  tool  for  this  purpose  and  OOD-STD-1467  provides  the  contracting  tool.  This  plan¬ 
ning  must  provide  for  the  efficient  turn-over  of  the  software  from  developer  to  cus¬ 
tomer.  Life  cycle  software  supportabi 1 1 ty  demands  more  up-front  attention  than  It 
historically  has  received. 
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SUMMARY 

The  scope  of  this  paper  is  to  define  an  expert  software  system,  implemented  in  Ada,  for 
avionics  in  the  1990'8,  using  a  table-driven  design  that  was  developed  in  a  demonstration 
program  as  the  prototype,  in  order  to  support  tactical  decision  making  applications.  As  a 
synopsis  of  what  follows  we  will:  point  out  the  relevancy  of  such  a  paper  to  the  avionics 
community;  give  an  historical  example  of  a  table-driven  design  in  the  area  of 
Reconnaissance  Management  Systems;  describe  the  design  logic  behind  this  historical  example 
by  providing  a  single  thread  through  the  system;  discuss  the  conceptual  enhancements  that 
need  to  be  folded  on  top  of  this  historical  example,  as  an  additional  layer,  in  order  to 
produce  an  Expert  Software  System;  and  provide  a  summary  highlighting  some  reasons  the 
avionics  community  should  move  in  this  direction  from  a  software  perspective. 


1.0  ZHTRODOCTIOM 

The  orientation  of  this  paper  is  from  the  user  perspective  and  will  develop  an  approach 
towards  a  user  friendly  Man-Machine  Interface  in  the  avionics  arena.  This  paper  is 
relevant  to  the  AVP  Symposium  because  it  addresses  the  avionics  life-cycle  process  using 
the  Advanced  Tactical  Air  Reconnaissance  System  (ATARS)  as  a  practical  example.  The 
primary  focus  of  this  paper  falls  under  the  Application  section,  specifically,  Tactical 
Decision  Making  in  the  area  of  Expert  Systems,  however,  the  paper  also  touches  other 
relevant  topics  such  as  Expert  Machines,  Han-Machine  Interlaces,  and  Ada  as  an  application 
language.  Currently,  there  is  a  need  for  avionics  systems  that  can  make  tactical  decisions 
with  minimal  operator  intervention.  In  today's  high-threat  environments,  modern  tactical 
reconnaissance  requires  adaptive,  flexible  systems  for  mission  success.  Crew  members  need 
to  focus  on  navigation,  aircraft  control,  and  threat  avoidance,  and  a  semi-intelligent 
system  will  facilitate  that  concentration. 

The  concept  for  such  an  Expert  System  evolved  from  the  video  reconnaissance  system 
prototype  developed  by  Control  Data  Corporation.  This  prototype  was  flown  by  the  United 
States  Air  Force  (USAF)  during  both  the  1986  Near-Real -Time  Reconnaissance  F-16  Flight  Test 
Demonstration  and  Concept  Validation  (F-16  Recce)  program  at  Edwards  Air  Force  Base, 
California,  and  the  1987  RF-4C  Advanced  Tactical  Sensor  Demonstration  (ATSD)  program  at 
Eglin  Air  Force  Base,  Florida.  The  demonstrations  were  designed  to  test  the  operational  as 
well  as  tactical  deployment  capabilities  of  Control  Data's  real-time  Reconnaissance 
Management  System  (RMS) ,  a  sensor  data  collection,  review,  and  transmission  system.  This 
system  supported  both  manual  and  semi-automatic  target  acquisition  and  data  link 
capabilities.  The  overall  system  evaluation  was  performed  by  Rome  Air  Development  Center 
(RADC) .  Before  discussing  the  RMS  prototype,  a  brief  discussion  of  reconnaissance  is  in 
order. 


2 . 0  BACKGROUND 

Historically,  military  commanders  have  been  dependent  upon  airborne  reconnaissance 
photographs  for  intelligence  decision  making  in  regard  to  strike  force  operations. 

However,  film  processing  is  not  only  cumbersome  but  also  very  time  consuming.  Developing 
film  in  the  battlefield  involves  transporting  bulky  equipment,  processing  chemicals,  and 
excessive  amounts  of  fresh  water.  Of  greater  concern,  however,  is  the  time  involved  with 
film  processing.  An  area  classified  as  a  high-value  target  may  no  longer  be  occupied  by 
the  time  the  film  is  processed  and  analyzed.  With  the  high  mobility  of  today's  enemy 
forces,  commanders  need  real-time  Information  in  order  to  make  accurate  tactical  decisions 
regarding  deployment  of  scarce  resources.  Consequently,  a  more  timely  method  is  needed  in 
order  to  provide  that  capability. 

The  U.S.  Air  Force  sought  to  replace  the  film-based  systems  with  an  integrated 
reconnaissance  system  that  would  include  a  video  management  system,  electro-optical 
sensors,  a  data  recorder,  a  data  link,  and  a  digital  imagery  ground  exploitation  system. 

In  response.  Control  Data  developed  the  airborne  RMS  and  the  ground-based  Imagery 
Management  System  (IMS) .  The  RMS  is  an  airborne  video  management  system  that  interfaces  to 
multiple  sensors,  either  electro-optical  or  infrared,  a  data  recorder,  and  a  data  link 
system.  The  RMS  provides  the  in-flight  capability  to  record,  recall,  review,  and  transmit 
pertinent  sensor  imagery  in  near  real-time. 
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For  both  the  F*16  Recce  and  RF'4C  ATSD  deeonstrationa,  the  in~fli9ht  data  link  operations 
and  post-flight  data  analysis  were  supported  by  RADC's  Ground  Station  systes.  The  Ground 
Station  is  a  mobile  ground  processing  and  exploitation  system  that  provides  photo  and 
imagery  interpreters  with  the  capability  to  perform  in-depth  analysis  of  post-mission 
reconnaissance  data.  Control  Data  designed  and  devel<^>ed  the  Imagery  Management  System 
(IMS)  based  on  the  airborne  RMS  in  order  to  provide  the  front-end  to  the  Ground  station 
that  is  necessary  for  real-time  processing  of  image  data  from  the  data  link  and  airborne 
tapes  into  a  video  display  format.  For  both  demonstrations,  the  IMS  provided  the  imagery 
interpreters  with  a  more  extensive  video  tape  display  and  control  capability  than  was 
provided  by  the  airborne  RMS.  RADc  evaluated  the  IMS,  and  results  proved  not  only  that  the 
IMS  worked  extremely  well,  but  also  that  softcopy  digital  reconnaissance  is  a  valid 
concept . 

The  previously  mentioned  demonstrations  evaluated  by  RADC  were  precursory  studies  for  the 
Advanced  Tactical  Air  Reconnaissance  System  (ATARS)  program.  The  ATARS  program  involves: 
upgrading  the  service's  current  RF-4C  reconnaissance  fleets  with  electro-optical  based 
video  feconnaissance  systems;  developing  a  follow-on  podded  version  for  the  reconnaissance 
aircraft  to  replace  the  RF-4C;  and  future  equipping  of  an  unmanned  air  reconnaissance 
vehicle.  The  demonstrations  successfully  validated  the  feasibility  of  developing  an 
electro-optical/infrared  sensor  based  video  system  with  excellent  results. 

Control  Data  was  the  prime  system  integrator  for  the  RF-4C  ATSD  program  and  was  responsible 
for  the  hardware  and  software  development  for  the  RMS  and  the  IMS.  Figure  1  shows  ^-he 
RF-4C  overall  major  Interfaces  at  a  functional  block  diagram  level.  For  this 
demonstration,  the  RMS  consisted  of  a  Data  Collector  (DC),  a  Display  Generator  (DG),  and  a 
Control  Panel  (CP) .  The  Data  Collector  accepted  sensor  inputs  and  combined  them  with 
aircraft  navigational  inputs  into  a  format  used  for  real-time  cockpit  display  and  storage 
on  a  data  recorder.  The  Display  Generator  accepted  live  or  recorded  inputs  and  processed 
the  input  data  for  presentation  on  a  video  display  or  for  data  link  to  the  Ground  Station. 
The  Control  Panel  provided  the  interface  between  the  aircraft  navigational  computer  and  the 
Data  Collector  as  well  as  providing  the  interface  between  the  operator  and  the  RMS. 
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RF-4C  Functional  Block  Diagram 

For  the  RF-4C  flight  tests,  the  RMS  had  four  major  modes  of  operation:  System  Status, 
Sensor  Data  Acquisition,  Sensor  Data  Review,  and  Data  Link.  The  System  Status  mode  showed 
the  viability  of  the  airborne  RMS  system  at  any  point  during  the  mission,  either  on  the 
ground  or  in  the  air.  The  Sensor  Data  Acquisition  mode  provided  the  capability  to  record 
sensor  imagery  data  and  mark  targets  of  interest  for  later  review.  The  Sensor  Data  Review 
mode  permitted  in-flight  review  of  the  recorded  sensor  imagery  and  manual  selection  of 
sensor  imagery  to  be  data  linked  to  the  ground.  Finally,  the  Data  Link  mode  provided  wide 
or  narrow  band  transmission  of  sensor  imagery  data  to  a  ground  station. 
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The  Data  Acquisition  mode  performed  either  manually  or  semi^automatically.  In  the  manual 
acquisition  mode,  the  operator  would  select  the  primary  and  secondary  sensors  most 
appropriate  for  coverage  of  the  desired  target,  turn  recorders  on  and  off  over  the  target 
area,  and  mark  the  target  as  it  was  overflown*  In  the  semi-automatic  mode,  the  operator 
would  still  select  the  sensors  to  use,  but  recording  and  marking  functions  were  performed 
by  the  RMS  matching  aircraft  geolocation  coordinates  with  target  coordinates  preset  by  the 
operator.  Since  acquisition  of  target  data  generally  occurs  in  hostile  territory,  the 
automatic  Acquire  mode  is  important  because  it  eliminates  the  distraction  of  system 
operations  when  full  attention  is  best  focused  on  tactical  maneuvers.  The  automatic 
Acquisition  mode  functions  also  demonstrated  the  feasibility  of  employing  an  RMS  on  a 
single  seat  aircraft  or  on  an  unmanned  vehicle  platform. 

The  Acquisition  mode  also  provided  a  variety  of  useful  video  display  options  such  as  Pause, 
which  froze  the  current  image  on  the  display;  Invert,  which  inverted  black  video  to  white 
and  vice  versa;  Compress,  which  compressed  the  video  in  the  along-track  direction, 
effectively  slowing  image  motion;  and  Target  Data,  which  superimposed  current  aircraft 
information  over  the  video  imagery. 

The  Sensor  Data  Review  mode  enabled  the  operator  to  recall  and  replay  portions  of  recorded 
imagery  that  were  marked  during  acquisition  at  either  a  real-time  rate  or  a  slower,  fixed 
rate.  Magnification  of  imagery  could  also  be  achieved  with  full  resolution  since  the 
system  recorded  high  resolution  sensor  data.  In  this  mode,  the  operator  would  also  select 
the  most  important  segments  of  imagery,  magnified  or  unmagnified,  for  data  linking  to  the 
ground.  Since  review  of  sensor  data  is  operator  intensive  and  time  consuming,  the  Review 
mode  is  an  optional  feature  and  is  generally  most  useful  in  friendly  territory  when  time 
permits. 


3.0  TAfiLB-ORIVBM  DESIdH  EXAMPLE 

The  RF-4C  Control  Panel  (CP  in  Figure  1) ,  which  was  the  Man-Machine  Interface  for  the  RP-4C 
RMS,  was  designed  as  a  state/table-driven  software  package.  Essentially,  the  software 
architecture  mirrored  the  Control  Panel,  which  was  comprised  of  programmable  display 
pushbuttons  (PDPs),  discrete  buttons,  and  a  keypad  as  shown  in  Figure  2. 

The  various  mission  modes  (e.g.,  data  acquisition),  as  well  as  options  within  a  given 
mission  mode  (e.g.,  sensor  selection),  were  encapsulated  in  the  form  of  tables  within  the 
processor  memory.  For  example.  Figure  3  depicts  the  operator's  options  as  a  series  of 
tables.  Table  3  is  the  currently  "executing”  table  in  memory,  which,  in  turn,  reflects  the 
operator's  current  menu  of  choices.  This  illustration  is  for  the  Acquire  Mode  as  shown  in 
Figure  2. 

For  each  selection  that  the  operator  makes  with  respect  to  the  menu  presented  in  Figure  2, 
the  following  sequence  occurs:  first,  the  software  is  vectored  to  the  appropriate  offset 
within  the  current  table  (Figure  3)  by  the  pushed  button  interrupt  type  (e.g.,  P6  which 
corresponds  to  the  COMPRESS  option  in  Figure  2's  menu);  second,  the  validity  of  that 
selection  is  checked  by  the  corresponding  boolean  entry  for  this  selection  (e.g.,  P6  is  a 
valid  selection);  next,  the  action  specified  for  this  selection,  which  in  this  case  is  to 
compress  the  real-time  imagery  on  the  cockpit  display,  is  then  executed  within  a  High  Order 
Language  (HOL)  CASE  construct  as  shown  in  Figure  4  below;  then,  new  messages  are  displayed 
on  the  Control  Panel  per  the  associated  message  index;  and  finally,  the  next  table  index 
field  is  used  to  update  the  current  table  in  memory  to  correspond  to  the  next  menu.  This 
process  is  then  repeated  until  the  mission  is  over. 

In  addition,  the  system  also  supported  the  capability  to  automatically  acquire  and  data 
link  target  information.  At  the  beginning  of  the  mission  the  crew  member  would  enter  the 
target  information,  in  terms  of  geolocation  coordinates,  into  the  data  base.  If  the 
operator  then  selected  the  automatic  target  acquisition  option,  the  RMS  would  process  the 
incoming  navigational  data  against  the  data  base  target  data  parameters.  In  essence,  the 
system  drew  two  imaginary  concentric  circles  around  the  target,  the  outer  circle  having  a 
radius  of  eight  miles  and  the  inner  circle  having  a  radius  of  about  three  miles.  When  the 
outer  circle  was  pierced  by  the  aircraft,  the  system  would  turn  on  the  recorder  just  as  if 
the  operator  had  depressed  the  record  button  (Figure  2) .  If  the  aircraft  proceeded  to 
enter  the  inner  circle  around  the  target,  the  system  would  then  mark  the  target  as  if  the 
operator  had  also  depressed  the  target  mark  button.  Marked  video  and  associated  aircraft 
data  were  saved  in  the  data  base,  and  subsequently  data  linked  to  the  ground  station, 
again,  as  if  the  operator  had  entered  the  Review  mode  and  pushed  the  data  link  mark  button 
to  select  imagery. 

This  capability  proved  extremely  useful  because  it  freed  the  operator  from  the  manual 
intervention  mode.  Reducing  the  number  of  selections  an  operator  has  to  make 
correspondingly  reduces  the  potential  for  errors  that  can  occur,  which  is  more  likely 
during  tactical  maneuvers.  Of  course,  this  capability  had  some  limitations.  For  example, 
since  the  targets  were  determined  a  priori,  there  was  no  automatic  method  for  acquiring  a 
target  of  opportunity.  That  is,  if  the  crew  member  determined  that  a  target  not  programmed 
in  the  data  base  was  nevertheless  a  target  of  interest,  then  the  operator  had  to  enter  the 
target  data  pareuneters  manually  after  manually  marking  it.  The  chance  for  errors  in  this 
manual  mode  increase  with  such  variables  as  speed,  target  mobility,  etc.  The  automatic 
acquisition  function  demonstrated  utility,  but  tne  concept  requires  some  additional 
refinement  to  be  truly  automatic.  This  increased  capability  is  discussed  further  in  this 
paper  during  the  treatment  of  an  Expert  System. 
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case  ACTION  of 
0  :  begin 

(  do  nothing  ) 
end; 


1  :  begin 

(  read  temperature  probes  ) 
end; 

{  . 


50 


.  ) 

begin 

{  compress  imagery  } 
end; 


(  .  ) 

end;  (  case  ) 


Figure  4.  HOL  Construct  for  Action  Field  in  Figure  3 


The  mission  mode  tables  were  statically  constructed  and  could  not  be  altered.  Prior  to  the 
mission  flights  the  tables  were  built  in  assembly  language  and  burned  into  Erasable 
Programmable  Read-Only  Memory  (EPROM).  The  tables  reflected  the  different  scenarios  that 
were  specified  by  the  system  requirements.  If  a  requirement  for  a  particular  sequence 
changed,  then  the  tables  were  modified.  The  code  was  only  changed  if  a  new  action  was 
specified,  but  the  changes  were  localized  to  the  CASE  construct  (Figure  4).  Consequently, 
validating  an  operator  selection,  performing  an  action,  updating  the  panel  POPs,  and 
transitioning  to  the  next  table  were  predetermined. 

This  behavioristic,  modular  approach  facilitated  system  requirement  changes,  integration, 
and  software  maintenance.  The  software  was  not  plagued  by  the  traditional  problems 
associated  with  non-table  driven  designs.  Requirement  modifications  did  not  ripple  all  the 
way  through  the  software  system,  which  saved  time  during  the  early  development  phase.  The 
integration  problems  that  lengthen  the  later  development  phase  of  software  programs  built 
on  traditional  logic  (e.g.,  IF  ...  THEN  ...  ELSE  ...)  were  avoided.  For  example,  anyone 
experienced  with  real-time  embedded  software  systems  development  must  be  familiar  with  the 
race  conditions  inherent  in  "flag"  driven  software.  In  addition,  there  was  minimal 
maintenance  requirements  in  terms  of  contractor  support  personnel,  which  is  cost  effective 
when  one  considers  the  burgeoning  costs  associated  with  software  maintenance.  Finally, 
this  approach  simplified  the  training  and  transition  cycle  from  contractor  to  customer  in 
that  new  personnel  did  not  have  to  learn  the  system  by  walking  through  all  the  attendant 
code  and  documentation. 

The  Control  Panel  software,  which  was  written  in  Pascal,  "executed"  tables.  In  effect,  the 
numbers  contained  in  the  tables  represented  pseudo  operation  codes,  which  extended  the 
processor's  instruction  set.  This  approach  is  less  dependent  on  hardware  architectures  and 
language  processors.  The  application  happened  to  use  an  Intel  B0188  processor,  but  could 
just  as  easily  have  used  a  Motorola  6809  with  the  code  generated  in  the  C  programming 
language.  The  design  would  not  be  impacted  if  the  prototype  went  into  production  on  the 
standard  1750  processor  using  Ada,  the  language  mandated  by  the  Department  of  Defense.  The 
portability  of  this  approach  across  processors  and  languages  is  clearly  a  desirable  trait. 

However,  despite  the  positive  characteristics  of  table-driven  software  designs,  there  are 
still  some  shortcomings  associated  with  such  an  approach.  For  example,  as  previously 
mentioned  under  the  discussion  of  the  automatic  target  marking  function,  the  system  was  not 
truly  automated  since  it  could  not  cleanly  handle  the  "target  of  opportunity"  case.  In  the 
manual  mode  of  operation  every  scenario  was  predetermined,  changing  a  course  of  action, 
based  on  a  new  set  of  variables  not  previously  encountered,  was  not  possible.  The  system 
could  not  infer  the  next  set  of  operations  in  this  case.  Finally,  in  the  manual  mode  of 
operation,  a  great  amount  of  interaction  was  required  on  the  part  of  the  operator.  A 
semi-intelligent  system  is  needed  to:  produce  an  even  more  user  friendly  Man-Machine 
Interface;  provide  a  fully  automated  acquisition  mode,  not  just  automatic  target  marking; 
expand  previous  automatic  target  marking  functions  to  handle  "targets  of  opportunity";  and 
deduce  a  new  sequence  of  operations  when  encountered  with  a  new  set  of  variables. 
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4.0  IXPBBS  SYSTIM  COMCBVT 

Our -concept  of  such  an  Expert  Systea  would  bo  built  on  the  table-driven  design  developed 
for  the  RF-4C  deaonstration  prograa.  Subsequent  avionics  systeas  (e.g.,  ATAHS)  could  be 
based  on  this  approach  with  the  following  progressions:  an  interpreter  would  be  added  that 
could  build  intelligent  tables,  i.e.,  tables  that  contain  decision  making  properties;  the 
application  would  bo  generated  in  Ada;  and  the  tables  could  be  constructed  dynaaically  as  a 
set  of  executable  packages  by  manual  and/or  voice  intervention.  For  instance,  the  operator 
could  select  a  aission  scenario  configuration,  which  would  cause  the  construction  of  the 
required  set  of  tactics  in  tabular  format  to  be  interpreted.  Since  we  have  not  designed 
such  a  systea  yet,  a  detailed  discussion  is  not  possible.  However,  this  paper  will  attempt 
to  sketch  our  approach.  The  layered  software  depicted  in  Figure  5  represents  a  high-level 
view  of  our  approach.  Please  note  that  the  outer  layer,  the  interpreter,  was  not  present 
in  the  RP-4C  demonstration  prograa. 


Mission  Inlormstion  Table 


Figure  5.  Layered  Software  Expert  Systeas  Approach 


Tables  would  be  at  t)ie  heart  of  this  system  just  as  in  the  previous  system,  but  with  some 
notable  differences.  First,  we  envision  two  different  kinds  of  tables.  The  first  set  of 
tables,  namely,  Adaptation  Teddies,  would  be  identical  to  the  RF-4C  approach.  That  is,  the 
system  would  support  the  RF*4C  static  mission  scenarios  as  a  subset  of  it's  overall 
design.  There  are  many  reasons  for  maintaining  the  architectural  design  from  our  previous 
example.  First,  there  is  no  foreseeable  replacement  for  real  intelligence,  which  is  the 
human  interface.  Therefore,  the  system  must  be  flexible  to  provide  the  operator  a  manual 
mode.  Second,  if  the  automated  mode  breaks  down,  then  a  fully  manual  default  mode  must  be 
available.  Finally,  the  Review  Mode  does  not  lend  itself  to  an  Expert  System 
implementation.  The  system  cannot:  "know"  that  the  operator  wants  to  review  any  imagery, 
since  this  mode  is  optional;  review  a  particular  piece  of  imagery;  or  select  areas  to 
magnify;  for  example.  Therefore,  we  have  targeted  the  Acquisition  and  Data  Link  modes  as 
candidates  for  Knowledge-based  software  systems. 

The  second  set  of  tables,  namely.  Mission  Information  Tables,  would  be  a  knowledge  base 
containing  current  information  required  by  the  Interpreter  (Figure  5)  to  automate  the 
Acquisition  and  Data  Link  mission  modes.  The  data  entries  presented  in  the  Mission 
Information  Tables  are  not  complete,  but  highlight  the  sort  of  data  needed  in  order  to 
modify  the  pregenerated  Adaptation  Tables  in  the  Acquire  Mode.  Parametric  data,  such  as 
aircraft  data  provided  in  real-time,  would  allow  the  Interpreter  to  make  decisions  about 
best  sensor  selection.  Supplied  data,  such  as  a  sensor's  Field  of  View  (FOV) ,  would 
augment  the  decision  making  process  for  the  Interpreter. 

The  Interpreter  would  execute  as  a  periodic  (e.g.,  1  second)  real-time  monitor.  It  would 
repeatedly  examine  the  Mission  Information  Tables  to  inierpret  the  current  situation  and 
construct  the  appropriate  Acquire  Mission  sequence.  For  example,  if  the  operator  was 
flying  low  and  fast,  the  Interpreter  would  build  a  menu  like  Figure  2  and  "depress"  the 
COMPRESS  POP  in  order  to  slow  the  imagery  for  viewing  purposes.  As  another  example,  if  the 
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target  coordinates  were  perpendicular  to  the  line  of  flight,  the  Interpreter  would  select  a 
side  oblique  camera  as  the  primary  sensor,  since  it  would  provide  the  best  coverage.  In 
essence,  the  Interpreter  is  constantly  selecting  the  Acquire  Mode  and  making  determinations 
about  which  sensor  will  provide  the  best  priaiary/secondary  coverage,  or  whether  imagery 
should  be  compressed  for  real-time  viewing,  for  example. 

The  automatic  target  marking  function  would  be  handled  analogously  to  the  relationship 
between  the  RF-4C  prototype  and  the  sami-intelligent  system  proposed  for  this  ATARS 
application.  That  is,  primary  targets  would  still  be  identified  in  the  data  base  prior  to 
flight  in  terms  of  geolocation.  The  Interpreter  would  compare  these  preset  coordinates 
against  current  aircraft  navigational  data  in  order  to  determine  when  to  mark  an  area  of 
interest  for  subsequent  review  and  data  link.  This  would  be  the  baseline  automatic  target 
acquisition  function  for  an  ATARS  syst». 

In  addition,  areas  of  interest  could  be  denoted  by  the  operator  in  terms  of  time.  Since 
the  Interpreter  would  execute  as  a  periodic  task  it  could  effectively  mark  areas  along  with 
the  specified  time  coordinates.  The  only  preset  parameter  needed  would  be  the  frequency 
interval,  which  would  specify  how  often  to  mark  areas  of  interest.  For  example,  if  the 
periodic  interval  was  specified  as  5  seconds,  the  system  would  store  time,  location  on 
tape,  and  current  video  image  pointers  in  the  data  base.  These  set  of  marks,  based  on 
time,  would  be  construed  by  the  system  as  a  secondary  set  of  marks.  The  operator  could 
then  recall  areas  of  interest  via  time,  instead  of  geolocation  coordinates,  if  so  desired. 
By  definition,  this  approach  solves  the  "target  of  opportunity"  case  in  the  sense  that 
there  are  no  specific  targets  or  "targets  of  opportunity". 

In  addition  to  using  geolocation,  using  time  as  a  coordinate  permits  the  construction  of  a 
video  road  map.  In  addition  to  the  current  exhaustive  post-mission  data  analysis  provided 
by  RADC's  mobile  ground  station,  it  could  generate  a  quick-look  report  by  reviewing  imagery 
based  mainly  on  time  interval  snapshots  taken  during  the  airborne  mission.  This  strip 
chart  could  be  produced  very  quickly  to  provide  information  to  imagery  interpreters  to  make 
tactical  decisions  about  targets  in  terms  of  rank,  category,  etc. 

Programming  the  application  in  Ada  adds  another  dimension  to  the  RP-4C  prototype  baseline 
for  this  ATARS  application  program.  The  RF-4C  program  was  implemented  in  Pascal.  For 
purposes  of  this  discussion  Ada  can  be  construed  roughly  as  a  superset  of  Pascal.  However, 
Ada  adds  some  essential  features  not  provided  by  Pascal.  The  use  of  Ada  as  the  HOL  within 
this  system  will  influence  the  design  processes.  The  primary  benefits  of  the  language  will 
be  it's  package  structure  and  strong  data  typing,  which  provide  a  highly  modular  design. 

The  semi-intelllgent  system  would  be  designed  in  a  layered  structure  to  ensure  a  flexible 
approach  to  software  development,  while  fully  utilizing  the  benefits  of  Ada  as  the 
implementation  language. 

The  tables  referenced  in  this  paper  can  be  constructed  as  a  set  of  executable  packages.  In 
turn,  the  development  of  the  various  layers  of  the  ATARS  program  (Figure  5)  can  proceed  in 
a  top-down,  modular  fashion  with  strong  interface  type  checking  between  the  layers  and  the 
tables.  Our  experience  has  shown  that  there  is  a  marked  savings  in  effort  during  the  later 
phases  of  a  program  (testing,  integration,  and  maintenance)  by  using  Ada  as  opposed  to 
other  languages.  The  reason  for  this  savings  is  two-fold:  first,  many  of  the  errors  that 
occur  during  the  integration  and  test  phase  using  traditional  languages  (e.g.,  FORTRAN)  are 
at  the  interface  level  between  software  modules;  second,  the  top-down  approach  using 
traditional  languages  does  not  permit  early  testing.  Ada's  strong  syntactical  type 
checking  between  modules  prevents  the  first  problem.  Ada's  separate  module  compilation 
(body  and  specification)  permits  bottom-up  testing  during  the  early  development  phase, 
which  provides  a  parallel  approach  in  terms  of  designing  to  test  early. 


5.0  CONCLUSION 

In  summary,  we  have  taken  the  RMS  Control  Panel  table-driven  design  from  the  RF-4C 
demonstration  and  discussed  conceptual  enhancements  necessary  to  produce  an  expert  system. 
First,  we  added  an  Interpreter  to  dynamically  build  intelligent  tables.  These  tables, 
namely,  Adaptation  Tables  would  be  an  extension  of  the  static  RF-4C  tables.  We  also 
introduced  Mission  Information  Tables  that  would  be  a  knowledge  base  to  record  current 
parameters  used  by  the  Interpreter  to  fully  automate  modes  of  operation.  The  expert 
system  would  control  the  system  configuration  and  manage  the  mission  modes  by  performing 
actions  consistent  with  the  current  set  of  tactics. 

The  concept  for  this  expert  system  is  based  on  the  premise  that  modern  tactical 
reconnaissance  requires  adaptive,  flexible  systems  for  mission  success.  We  used  the  RMS 
Control  Panel  as  a  practical  expert  system  application  since  it  has  relevance  in  the 
avionics  community  right  now.  Currently,  in  the  ATARS  program,  there  is  a  need  for  an  RMS 
to  interface  to  multiple  vehicle  platforms,  manned  and  unmanned.  Since  the  expert  system 
provides  fully  manual  and  automated  modes  of  operation,  this  design  concept  will  facilitate 
that  need,  and  will  reduce  the  cost  of  software  development  from  the  design  level  through 
maintenance  in  the  avionics  software  life-cycle  process. 
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DISCUSSION 

ILW.MacPlienoii,  Ca 

How  do  the  pilots  feel  about  never  having  the  same  menu  appear  twice? 

Author’s  Reply 

The  panel  always  defaulted  to  the  same  menu.  The  demonstration  panel  was  designed  jointly  with  the  USAF  backseat 
operators  that  flew  the  test  missions  and  those  curators  liked  the  panel.  The  functions  on  the  menu  appear  in  the  same 
position  on  the  panel  during  the  mission  but  may  reflect  a  different  state  of  the  function. 

WAlansel,  Ge 

Could  the  pilot  in  the  automatic  acquisition  mode  decide  to  initiate  an  attack  when  having  a  target  acquired  or  was  it  a 
full  automatic  attack  mode? 

Author’s  Reply 

The  system  performed  only  acquisition  (and  data  link)  of  reconnaissance  data.  It  had  no  attack  mode.  For  target 
acquisition,  there  was  both  a  manual  and  automatic  mode.  The  operator  would  select  the  automatic  mode  prior  to 
entering  the  target  area. 
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ABSTRACT 

BecAUM  of  th«  incroMlng  eompkxlty  of  dlgUftl  ckealU,  it  If  bocoming  more  and  more  difficult  to  determine 
whether  a  circuit  ic  correct  or  faulty.  Fhulte  in  a  circuit  can  hardly  be  detected  just  by  looking  at  the 
outeide  what  the  reaction  of  the  circuit  Is  to  a  certain  input  sequence.  Fault  tolerant  computing  can  be 
a  solution.  Built-In  Self  Test  (BIST)  techniques  can  also  be  used  to  verify  whether  the  circuit  is  correct, 
not  only  during  normal  operation  (e.g.  every  time  upon  power-on),  but  also  during  the  early  development 
periods.  The  result  of  using  BIST  techniques  is  a  considerable  reduction  of  the  time  between  design  and 
the  final  product,  and  a  reduction  of  maintenance  time  and  cost. 

BIST  is  a  test  method  of  which  the  circuit  (on  a  board,  a  chip  or  a  part  of  a  chip)  can  separate  itself  from 
the  surrounding  logic,  and  perform  a  (self)  test.  After  the  self  test,  the  circuit  reports  to  the  surrounding 
lo^c  whether  it  is  correct  (a  so-called  go/nogo  test).  The  advantage  of  BIST  is  that  it  is  a  universal  and 
systematic  test  method  with  a  solid  mathematical  foundation.  Based  on  the  stuck-at  fault  model,  it  is 
possible  to  compute  the  fault  coverage,  which  is  the  number  of  faults  detected  by  the  BIST  method. 

In  this  paper  the  theory  of  BIST  is  described.  A  circuit  Is  divided  into  combinationaJ  and  sequential  parts, 
which  are  tested  separately.  The  sequential  parts  are  tested  with  a  so-called  scan-path  test.  Alternative 
test  methods  to  test  the  combinational  parts  are  described,  and  one  of  these  methods  (using  pseudo-random 
pattern  generators  and  CRC  signature  analysers)  is  described  in  more  detail.  The  method  to  compute  the 
number  of  patterns  needed  to  detect  all  faults  with  a  certain  probability  as  function  of  complexity  of  the 
circuit,  is  i^en.  The  theory  of  CRC  signature  analysers,  and  the  probability  of  masking  are  also  described 
and  illustrated  with  some  (small)  examples,  which  can  directly  be  used  in  practice. 


1  INTRODUCTION 

Over  the  yean  masy  different  approachee  to  teetlng  digital  circnite  have  been  developed.  One  of  theee  approachee  ie 
Bnilt-In  Self  Ihet  (BIST).  BIST  la  becoming  more  and  more  Important,  becanee  of  the  increasing  complexity  of  VLSI- 
circnlti.  Thaee  circolta  can  hardly  be  teeted  Joet  by  looking  at  the  outeide  what  its  reaction  ie  to  a  certain  input  eequence. 
There  hae  to  be  a  circuit  inside  the  chip,  which  reporte  whether  the  chip  is  correct. 


Fignrt  1:  The  four  pnrts  in  which  n  circuit  can  be  divided 
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A  circalt  (almoct  avtry  circuit)  cun  bu  divided  into  four  purta  (ue  Figure  1): 

1.  reglaten 

Regietere  compriee  uU  memory  elemente,  e.g.  re^tere,  lutcbee,  Sip-tope,  but  not  memory- arrays  like  RAM. 

2.  interior  logic 

Interior  logic  it  that  part  of  the  combinational  logic  which  it  surrounded  by  registers. 

3.  exterior  logic 

The  combinational  logic  which  is  not  surrounded  by  registers  u  called  the  exterior  logic.  An  example  of  exterior 
logic  are  the  I/O  buffers  of  a  chip. 

4.  memory 

The  last  part  which  can  be  distinguished  consists  of  memory  arrays  (e.g.  RAM/ROM). 

Testing  the  above  four  parte  requires  different  test  methods.  These  methods  are; 


1.  SCAN.PATH  TESTING 

This  method  is  used  to  test  the  registers  of  the  circuit.  It  will  be  described  in  Section  2. 

2.  INTERIOR  lOGIC  TEST 

The  interior  lo^c  is  tested  with  a  interior  logic  self  test  method,  see  Section  3. 

3.  BOUNDARY  SCAN  TEST 

The  exterior  logic  is  tested  with  a  test  technique  catted  Boundary  Scan  tasting,  see  Section  4. 

4.  MEMORY  TEST 

Memory  (RAM/ROM)  can  be  tested  with  the  same  test-method  as  registers,  but  this  would  result  in  too  much 
hardware-overhead,  or  too  much  test-tlma.  It  therefore  is  tasted  with  specific  RAM/ROM  tests,  which  are  not 
described  in  this  paper.  For  more  information  see  |1),  [2],  [3]  and  |4]. 

The  oririnal  circuit  is  configured  such  that  during  self  teat,  a  teat-controller  controls  the  data  and  the  control-signals  of 
the  circuit.  The  test-controller  is  a  so-called  *state-raachine*  (a  sequencer),  which  is  brought  into  several  states  during 
the  self  test,  depending  on  the  previous  state  and  the  values  of  the  incoming  signals.  This  ’state-machine*  controis  each 
stage  of  the  self  test  and  reports  the  test-result  to  the  ’outside  world’,  i.s.  the  logic  that  started  the  self  test  of  the 
circuit. 

Note  that  the  partitioning  described  above  (i.e.  the  division  of  the  circuit  into  registers,  interior  logic,  exterior  logic  and 
memory),  is  not  only  useful  to  test  a  chip,  but  also  to  perform  a  self  test  for  a  board,  or  a  part  of  a  chip, 

2  SCAN-PATH  TESTING 

The  first  thing  one  has  to  know  before  the  other  parts  of  the  circuit  are  tested,  is  whether  the  registers  are  functioning. 
This  is  important,  because  these  registers  are  used  in  the  tests  for  the  remaining  parts  of  the  circuit.  The  registers  are 
tested  using  a  test  technique  called  tean-patk  tesA'ng. 
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Figure  2;  The  regjsteie  of  a  circuit  connected  as  a  string 
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During  a  scan-path  teet  the  registen  are  connected  with  each  other  to  form  a  string,  called  scan-path  (see  Figure  2), 
through  which  a  certain  pattern  it  shifted.  When  the  seme  pattern  appears  at  the  output,  all  registers  of  the  string 
work  correctly.  A  register  should  be  re-configured  such  that  during  the  scan-path  test  phase  the  pattern  can  be  shifted 
through  the  regietere.  These  re-configured  restore  are  called  scan-path  elemenU.  A  scan-path  element  is  a  flip-fiop  or 
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1  ktch  with  fom*  octn  lofie,  iiMdtd  to  partorm  »  Bomml  foactioB  dnriag  Bonnml  operation  and  to  perforin  a  ican-path 
(unction  dorinc  the  ecan-path  teet.  An  impleinentatioB  ie  given  in  Figure  3. 


NORHAL -DATA-IN 


NORNAL-CLOCK 


TEJT-aOCR 


Figure  3;  A  ecan-path  element 


During  normal  operation,  the  tegbter  ie  controlled  by  the  *normal-clock*-Rignal,  and  the  'normal-data-in*  input  ii 
■elected.  During  the  ecan-path  teat  phaee  the  aignal  *teet*  ie  active,  the  ragUter  ie  controlled  by  the  *tMt-clock'-iignal 
and  the  data  from  the  praviona  acan-path  element  ie  need  ae  data-inpnt  (through  the  *>can-in* -aignal).  The  acan-path 
elemente  ate  connected  with  each  other  during  the  teat  phaee  by  connecting  *tcan-ont*  of  the  previoua  with  *tcan-in* 
of  the  next  ecan-path  element.  The  teat-controller  controla  the  algnals  ’teat-clock*  and  *teat*.  It  alao  aends  a  certain 
pattern  into  the  flrat,  and  checke  the  pattema  coming  from  the  laet  acan-path  element  of  the  atring.  When  they  ara  equal 
the  ragietere  are  correct. 

Now  that  one  knowa  how  the  ecan-path  elemente  look  like,  one  hae  to  know  which  pattema  ahould  be  ahifted  through  the 
regleter-etring  la  order  to  be  eure  of  a  correct  working  of  the  memory  elemente.  Before  thia  qnaetlon  can  be  anawered, 
one  hae  to  Snd  out  what  fonlte  can  occur  In  a  regiatar.  An  enumemtlon  of  theae  faulta  ia  given  below: 

1.  a  ragiater  la  etnck-at-one 

3.  a  regieter  ia  atnck-at-aero 

3.  a  regieter  cannot  undergo  a  0  -•  1  tranaition 

4.  a  regieter  cannot  undergo  a  0  ->  0  tranaition 

5.  a  ragiater  cannot  undergo  a  I  -•  0  tranaition 

3.  a  regieter  cannot  undergo  a  1  ->  1  tranaition 

In  order  to  teat  theae  faulta,  the  following  pattern  can  be  ahifted  through  the  acan-path  elementa: 

001100110011001100110011 

The  four-bit  pattern  0011  ia  repeated  until  it  haa  reached  the  last  acan-path  element.  Firat  a  *0’  ia  ahifted  into  the  atring 
in  order  to  teat  whether  a  ragiater  ia  atuck-at-one.  The  aecond  *0’  which  ia  ahifted  in  the  atring  ia  to  check  whether  the 
regiatar  can  undergo  a  0  -•  0  tranaitioB.  Then  a  ’1’  ia  ahifted  in  the  atring.  Thia  b  done  to  check  whether  the  regbter  b 
atnck-at-aero,  and  to  check  whether  the  regbter  can  undergo  a  0  ->  1  tranaition.  The  aecond  ’1’  which  b  ahifted  in  checka 
whether  the  regbter  can  undergo  a  1  -*  1  tranaitloB.  Then  the  pattern  ia  repeated,  eo  the  next  bit  which  la  ahifted  in  ia 
a  V,  ao  alao  the  1  -•  0  tranaition  b  teated  (aee  alao  [5)). 

3  INTERIOR  LOGIC  TEST 

A  general  model  for  the  interior  logic  teet  b  ahown  in  Figure  4. 


Figure  4;  Global  model  fbr  the  btarior  logic  teet 

Thb  ^obel  model  of  the  Interior  logic  teet  b  genmally  accepted.  The  Input  Pattern  Qenemtor  (IPG)  generatea  aaveral 
pattema,  which  reauH  ia  a  certain  reaponea  on  the  out^t  Unea  of  the  Circuit  Under  That  (CUT).  Th»  That  Data  Evaluator 
(TDE)  avaluatee  the  reaponae  and  determinaa  whether  the  CUT  b  correct.  The  teat-controlbr  eontrob  the  IPG  and  the 
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TDE.  Tk*  CUT  if  th*  lat«iior  tock,  f<«Utilin  bo  ngiiUn,  m  Um  CUT  k  •  eombiutioail  ckcsit:  a  patten  oa  the 
bipat  of  the  CUT  aCaeta  tka  oatput-Saaa  dkaetlsr. 

la  tkk  aactioB  tka  loUoeriBg  aubjaeta  wiU  ba  dlacaaaad: 

1.  FAULT  MODELS 

Bafota  tka  bpat  Pattan  Ganatatoia  eaa  ba  daacribad,  tka  modak  of  tka  hnlta  wkick  ara  poaaibk  in  the  CUT  ara 

^an. 

1.  mrxrr  pattern  generators 

Saaaral  arapa  to  Impkmaat  aa  lapat  Pattaia  Gaaarator  an  pnaaatad.  Thalr  fault  covaraga  (tka  number  of  potential 
bulta  tkat  can  ba  dataetad,  dhrldad  bjr  the  total  aambar  of  poaaibla  taulta)  k  calculated,  aaaumlng  a  certain  fault 
modal. 

3.  TEST  DATA  EVALUATORS 

Tka  ontpnta  of  tka  CUT  moat  ba  aaalaatad  by  tka  Tkat  Data  Evaluator  of  wkick  Mveral  implementation  alternativei 

an  piaaaatad. 

3.1  FAULT  MODELS 

Bafon  tka  iatarior  logle  teat  taekniquaa  an  daacribad,  tka  faulta  tkat  caa  occur  in  a  VLSI  circuit  are  discuased.  Tka 
pkytleal  faulta  ocearriaf  la  VLSI  cinulta  wiB  ba  modelled  witk  logical  faults.  A  physical  fault  depends  on  the  design 
rules,  maanfaetafiag  ptocaaaea  and  chip  technology  (CMOS,  NMOS,  ECL,  TTL,  etc.),  wkik  a  logical  fault  is  almost 
tecknoiogy  kidapaadaat  and  tkanlbn  mon  uaaful. 

In  tkk  saetioB  four  logteal  bnlt  modek  will  ba  dkcusaad; 

1.  Stack>at4>  aad  Stnek-at-l  Fault  Modal 

The  atuck-at-O  and  stnek>at-l  fault  modal  k  tka  moat  frequently  used  fault  model.  A  fault  of  this  type  occurs 
whan  a  ekcult  Una  or  node  nmabis  at  Ita  logical  value  (*0*  or  *1’).  Tka  stuck-at-model  k  very  popular,  because 
its  inluaaca  oa  tka  logical  value  of  tka  circnlt-llaa  or  -node  k  easy  to  understand  and  to  implement.  The  stuck-at 
modal  covan  about  flOK  of  aU  physical  faulta  f6|. 

3.  Stnek>at-opaD  Panlt  Model 

Tka  stnck-at-opaa  fault  modal  nprusents  an  unhtandad  open  input  of  a  gate.  Tka  nmaining  logical  value  of  the 
opaa  line  depends  on  tka  used  technology.  If  the  used  technology  k  for  instance  TTL,  than  an  open  line  gets  the 
l^kal  value  T*.  An  open  Una  in  TTL  can  tharefon  be  represented  by  the  stuck-at-1  fault.  When  on  the  other 
hand  tka  used  technology  k  CMOS,  a  compktaly  diffannt  situation  occnn;  the  capacity  and  high  impedance  of 
the  CMOS  tranaktor  makaa  the  behaviour  of  the  faulty  circuit  become  saquentiaL  Because  these  faults  only  occur 
with  CMOS  technology,  tkk  modal  k  not  (jrat)  genaraUy  used. 

3.  Conpling/Bridglng  Panlt  Modal 

The  bridgtag  or  coupling  bult  modal  repraaanta  the  group  of  faults  that  occur  when  two  or  more  points  of  the 
circuit  ara  connected.  Sometimes  thk  kind  of  faults  can  also  be  modeUed  by  the  stuck-at  model. 

4.  Pattern  Sanaltlvs  Panlt  Modal 

The  pattern  sensitive  bnlt  model  represents  faults  that  occur  as  a  result  of  the  change  (or  the  impossibility  to 
ckanga)  in  a  logdua)  value  due  to  tka  prasanca  of  a  specific  pattern  of  logical  values  at  certain  points  in  the  circuit. 
Tkk  fault  occurs  mainly  in  mamoiy  chips.  The  fault  k  often  a  result  of  memory  ceUs  being  very  close  together 
(high  physksl  density),  and  occurs  more  often  in  dynamic  than  in  static  memory. 

3.3  INPUT  PATTERN  GENERATORS 

As  said  in  the  introduction  of  thk  section,  the  global  modal  of  the  interior  logic  test  conskts  of  four  parts,  namely  the 
Input  Pattern  Generator  (IPG),  the  Circuit  Under  Tbst  (CUT),  the  Test  Data  Evaluator  (TDE)  and  the  test-controller. 
In  thk  subsection  the  IPG  will  be  discussed. 

The  IPG  generates  patterns  which  result  In  a  certain  response  of  the  CUT,  observable  on  the  output  of  the  CUT.  Three 
types  of  IPGs  can  be  dktingukked,  namely; 

1.  EXHAUSTIVE  INPUT  PATTERN  GENERATORS 

2.  DETERMINISTIC  INPUT  PATTERN  GENERATORS 

3.  PSEUDORANDOM  INPUT  PATTERN  GENERATORS 

S.a.l  EXHAUSTIVE  INPUT  PATTERN  GENERATORS 

The  unkaustive  input  pattern  generutor  generatet  ail  poastbk  pattens.  Thk  type  of  IPG  can  detect  almost  all  faults  in 
the  CUT,  sad  k  tketefoie  almost  the  ideal  IPG.  The  only  (big)  disadvantage  k  the  large  number  of  patterns  needed  to 
test  the  circuit,  namely  3"  (»  k  the  number  of  taput  pint).  When  n  >  3S,  wkick  happens  very  often,  the  time  needed 
to  genatate  all  pattens  becosnes  too  largs.  In  tkat  ease  the  stiuctuiu  of  the  circuit  most  be  evaluated  in  order  to  reduce 
the  number  of  pattens.  Thk  caa  be  done  by  dividing  the  circuit  into  several  smaller  parts  (partitioning)  (|7),  |8)). 
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Aa  «xka««UT*  IPG  )■  ikom  )a  llfiin  $.  It  gaiuntM  Uk«  toUowini  pattanx  (whan  •tuting  with  0000); 
0000,  lOOO,  0100,  0010, 1001, 1100, 0110, 1011,  0101, 1010, 1101, 1110,  nil,  0111,  0011,  0001,  0000 . 


Flfon  t:  An  «h«utiir«  patUn  gaatrator 

Tha  axhanatiaa  IPG  of  Flgnia  S  eonabta  of  a  ao-callad  Usaat  faadback  thifl  taglatar  (LFSR).  Thii  LFSR  is  a4iusted  is 
•och  wap  that  It  piodaeaa  all  poasibk  pattans  (Inclodisf  tha  all-saro  pattara)  (saa  also  |9),  |SJ). 

1.3. a  DETHaMINlSTIC  INPUT  PATTEKN  GENERATORS 

Tha  datanBlsistle  Inpnt  pattan  ganatator  gasarataa  tpaelle  pattans,  which  waia  calcuUtsd  daring  the  design-phase  of 
the  eirenit.  Tha  datarminlatk  inpot  pattan  ganantor  nsas  tha  pia-calcnlatad  pattane  to  datact  all  poesible  faults  of 
tha  choaaa  knit  modal.  Thaaa  pattans  can  be  stond  la  ROM  on  tha  chip  (tha  gaaantlon  is  than  called  non-concurrent 
genaratloa),  or  they  caa  ba  gaaantad  la  a  *clatrar*  way  (coacurraat  gaaantioa)  ([10]).  la  most  casas  the  pattans  cannot 
M  smmXti  eoncunantly,  so  tha  datarmlnlstic  pattans  must  ba  storad  requiring  a  ROM,  which  will  increase  the  chip 
area  (ia  moat  caaas  this  area  will  ba  too  latga). 

Three  types  of  datarmlnlstic  IPGs  can  ba  distinguished; 

1.  Bahavtovral  IPGa 

Tha  bahaaloaral  IPGs  treat  tha  CUT  as  a  black  boa.  Only  the  function  of  the  CUT  ia  known,  not  the  way  it 
has  been  implamaatad.  Whan  tha  bahaTloural  IPG  ia  need,  it  Is  not  known  which  and  how  many  faults  will  be 
datactad.  Thatafon  tha  behavioural  IPG  will  only  ba  used  whan  tha  intanal  stncture  of  the  CUT  it  unknown  or 
vary  diflealt  to  undaratand.  Tharafota  this  type  of  datarministie  IPG  is  not  used  as  an  interior  logic  (self)  test 
pattan  ganantor. 

2.  Ponctloaol  IPGs 

The  Auctional  IPGa  ara  used  when  a  little  more  ia  kaovni  about  the  intanal  structure  of  the  CUT  (the  CUT  is 
treated  aa  a  gray  boot).  I\uctlonal  testa  an  partkalarly  naaful  whan  tha  implamantation  of  a  circuit  it  known  at 
a  U^ar  loval  of  abatmtion  (for  example  at  tha  datvpatk  level)  or  too  complex  to  understand  in  detail.  They 
caa  also  ba  assd  to  obtain  taatabBlty  Information  during  tha  early  atagaa  of  tha  design  phase,  when  the  intenal 
details  of  modules  ara  not  avallnbls.  Since  gate  lavd  models  n»y  not  cover  all  physical  failnrss,  functional  pattans 
an  also  naad  to  cheek  out  tha  circuit  at  opanting  speeds.  These  pattans  have  also  the  advantage  that  invalid 
or  iHagal  inputs  an  not  applied  to  tha  circuit.  Functional  testing  can  bu  used  in  addition  to  other  interior  logic 
taat  methods  in  order  to  ^aek  spaciSc  fnnctiont.  This  method  will  not  ba  used  ia  those  esses  where  the  Intenal 
structnn  of  tha  circuit  is  known,  and  the  input  patterns  have  to  ba  stored.  It  thanfon  is  not  often  used  for  a 
cklp-lsval  (buSt-in)  saU  test. 
i.  Stractnral  IPGs 

Tks  structural  IPG  caa  ba  used  whan  tha  compiata  stnctnn,  every  gate  of  the  CUT,  is  known.  Baaed  on  a  certain 
fouK  modal  (for  instance  tha  stuck-at  foult  modal),  tha  spscilc  patterns  which  detect  all  faults  can  be  computed. 
Utasa  pattans  caa  ba  computed  by  hand  or  with  the  use  of  a  computer.  But  bacausa  of  the  large  chip  area,  this 
Uad  of  IPG  wiU  not  ba  ussd. 

5.3. «  PSEUDORANDOM  INPUT  PATTERN  GENERATORS 

PsandoTundom  pattan  gaasntion  is  often  used  whan  axkanstivs  tasting  is  not  possibls,  bacausa  of  the  large  number 
of  patterns  sad/or  whan  tha  GUT  doss  not  allow  datarministie  tasting,  bacausa  of  tha  storage  required  for  the  input 
pattans.  A  problem  with  pseudorandom  tasting  is  whan  tha  result  of  tha  self  test  J  posttivs,  one  will  not  have  a  100% 
certainty  that  tha  circuit  la  corrset,  bacausa  of  tha  probabilistic  nature  of  tha  test.  Tha  question  with  pseudorandom 
input  pattan  ganaratois  is  how  many  patterns  should  ba  gaaantad  in  order  to  obtain  a  certain  probability  of  detecting 
all  fonits  of  tha  stuck-at  fault  modal  (a4.  or  SS%).  Aa  answer  to  this  question  can  be  obtained  in  two  different 
ways; 


1.  By  shnsilstlin  tha  dreslt  and  insartlag  fouMs.  Now  It  is  possible  to  datarmina  tha  exact  probability  of  not 
dataetiag  a  fUnlt  with  a  cartaln  number  of  pattans  (the  tsst-kagth).  It  ia  also  poasibla  to  calcnlata  tha  teats 
kngtk,  if  tha  probaUB^  that  a  foult  is  datactad  Is  girsa.  Simulation  takas  much  (often  too  much)  develop-  and 
compntingtims. 
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1.  By  «^rwrtin«thn  th*  tMt-knftk  (U.  tk*  aambtr  of  pattuu  ikMd«d)  ud  approximating  the  probability 
tkat  faolta  fai  tka  citcaH  will  lot  b«  datoetod.  Tkla  matkod  takaa  laai  time  than  •imnlation,  but  it  requlne  the 
dataetabllity  proUa  of  tka  eireiit. 

Ii  tkla  p^ar  oily  tka  aaeoid  any  of  datarmlnlBg  tka  probability  of  not  datacting  a  (etuck-at)  fault  will  be  discuaied, 
baeaua  tlm  raailta  kaaa  baan  ikoam  to  ba  wtiifaetaiy  ({11],  |S|),  and  tha  Ant  method  (limulating  the  circuit,  and  all 
poealblt  balta)  la  often  not  niafnl  la  praetiea  (K  would  ti^a  too  mnck  time). 

Tha  foDowinf  aepacta  of  paandonndom  input  pattara  tanaratora  will  ba  dlacuaead: 

1.  no  DataetuMUty  Praflla 

Tka  probability  of  not  datacting  a  (atick-at-)  fault  la  baaad  on  the  detectability  protle  of  the  circuit. 

2.  CoupntaUaa  of  tha  Bxpaetad  Ikolt  Covaraga 

Tha  datactablUty  profUa  ia  aaadad  to  caicnlata  tka  axpactad  fault  coverage,  which  givea  an  Impreseion  of  the  number 
of  puttama  naaM  to  teat  tha  circuit  with  a  paandorandom  input  pattarn  generator. 

3.  Implanaiitatiaiia  of  Paandoraadom  Pattara  Gaaaratora 

After  praa anting  tha  theory  of  tha  paandorandom  pattern  genantora,  the  way  theaa  IPGi  can  be  implemented  will 
ba  daacribad. 

The  DatactablUty  ProfUa 

In  tkla  aibaactlon  a  way  to  caicnlata  tha  fanlt-charactarlatic  of  a  combinational  circuit  needed  to  calculate  the  expected 
teet-laagtk  win  ba  diaenaiad.  Pint  a  dalnition  of  tka  datactablUty  proftle  ia  given: 

Tka  ddedaKWy  preflfe  H  la  tka  number  of  (atnck-at-)  faulta  tkat  are  datactad  by  a  certain  number  of  input  patterne. 

The  detectabiUty  proflle  H  ia  axpreaaad  aa  a  vector  [ki,he, ..-ihN].  Element  ha  of  tha  vector  la  the  number  of  faulta 
ia  the  circnlt  that  can  be  detected  with  h  input  patterne.  The  concept  of  the  detectability  prolle  will  be  explained  by 
meana  of  two  axamplaa. 

Txampfe  i 

Coalite  the  circuit  in  Fignra  6.  Thera  are  alx  poaaible  atnck-at  faulta:  ci/0  (connection  C)  atuck-at-iero),  ci/1 
(<i  atnck-at-ona),  ci/0,  ci/t,  ca/0  and  ca/t. 


Figniu  6:  tha  taat  circuit,  a  NOR  gate 

Than  ara  four  poaalbla  input  puttama.  If  tha  input  pattern  ia  00  (xi  =  0  and  xe  =  0),  then  the  normal  output 
win  ba  (xi  ss  1),  Tha  fault  Ci/1  win  reault  in  u  output  ai  s  0,  which  la  a  wrong  output.  Thii  ia  the  only 
puttaro  which  datacta  tka  fault  Ci/l.  Tha  faulta  ci/0,ci/0,ca/l  and  Cs/0  are  alao  detected  by  only  one  pattern 
(numaty  raapactivaly  tha  puttama  10, 01, 00  and  00).  So  there  an  five  faulta  that  ara  detected  by  only  one  pattern, 
thanfon  h|  =  S.  No  fault  ia  datactad  by  only  two  puttama  (ha  w  o),  one  fault  la  detected  by  three  patterne 
(namely  tha  fault  Ca/1,  which  la  datactad  by  tha  puttama  01, 10  and  11),  and  no  fault  ia  detected  by  four  patterne 
(he  =  0).  Thia  raanlta  ia  tha  datactablUty  proSla  B  w  |h|,hs,h«,ha)=  |S,0, 1,0|. 


Bxamph  M 

Compute  tha  datacUbiUty  prolle  H  for  tha  circuit  of  Figun  T. 


Figun  T:  The  circuit  of  Example  3 


Than  an  34  poaalbla  (atuck-at-)  faulta,  two  for  each  connection  e,-.  The  number  of  diffennt  input  patterne  ia 
33  (bacuaaa  than  an  3  input-Uaea).  Ibr  every  fault  the  number  of  pattaraa  which  detect  that  fault  haa  been 
computed,  by  Introducing  that  butt  and  eomputtag  tha  vatua  of  xi  for  all  poaalbla  puttama  on  the  input  Unea. 
Tha  number  of  tlmea  tha  vutaa  of  xi  diffan  from  tha  correct  value  of  xi  ia  tha  number  of  puttama  that  detect  that 
buK.  Thla  la  dona  for  aU  poaaibb  bulb  b  tha  drcuit.  Tha  neoH  b  givea  in  Tbbb  1. 
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TUi*  1:  Tk*  number  of  pstUra*  tkst  dotact  a  (poci&c  fault  in  tka  circuit  of  Figura  7 


number  at 
patterns 

fkolt 

mambar  of 
patUrni 

1775" 

« 

ct/O 

1 

‘i/» 

6 

Cr/1 

6 

es/O 

« 

ce/O 

4 

<a/l 

6 

ra/1 

9 

es/O 

4 

Ca/O 

8 

«s/l 

4 

*a/l 

0 

ct/0 

4 

«ia/0 

6 

4 

32 

Cs/O 

4 

Cu/0 

4 

«s/l 

4 

cu/1 

22 

cafO 

4 

<ia/0 

22 

call 

13 

Cull 

10 

Tka  datactnblUty  proUa  ottha  ehrcnlt  of  Figura  T  ia  H  v  [ki,kaika,k4,"',kaal  conaiata  of  tha  following  atamanti; 
ki  9  1  (tkara  la  ona  fuit  tkat  b  dataetad  bjr  onlp  oaa  pattara),  ka  >•  p  (tkaia  ara  nlna  faulta  that  ara  datactad  by 
tour  pattama),  ha  •  T,  ka  •  1.  k«  «  1,  kia  »  t,  ku  ■  li  kai  =  3  and  all  otkai  abmanta  of  H  ara  aaro. 

□ 

Tka  datactabUlty  proflb  of  nroat  elicnib  b  aary  dilBcnlt  to  obtain.  Tkara  an  tkraa  waya  of  calculating  the  detectability 
prolb,  namaly: 


1.  Bxkauathraly  fault  aimnlatloa.  Tkb  b  a  brata  force  matkod,  which  takaa  (often  too)  much  time  (for  large  circuita). 
In  Ebcampb  1  and  Bxampb  3  tkb  nathod  waa  aaad  to  explain  tka  datactabUlty  protla  for  two  limple  circuita. 

1.  Another  approach  wkbk  abo  takaa  naek  time  b  tka  D-algoritkm,  which  can  be  uaad  to  tnd  the  exact  proSta. 
Tkb  method  can  only  ba  uaad  for  amaO  circalta.  {.1S| 

3.  Tha  third  method  naaa  an  approximatloa  tackniqua.  b  (3|  a  way  to  cakulata  an  approximation  of  the  detectability 
protb  b  daaeribad. 


Computation  of  the  Expected  Fatilt  Couerage 

Tha  axpcetad  fault  covaraya  b  tha  fraction  of  potential  bulta  In  tka  circuit  tkat  can  ba  detected  by  applying  a  specific 
number  of  paaudorandom  input  pattarna.  Tha  expected  fault  coaaraga  can  ba  uaad  to  gat  Insight  In  tha  number  of  patterns 
needed  to  obtain  a  curtain  probabiUty  of  detecting  all  faulta.  Before  tha  expected  fault  coTarage  can  ba  calculated,  the 
datactabUlty  of  a  fault  muat  ba  deftn^: 

Tka  dalutaUHtf  k,  ol  a  fault  b  tha  number  of  pattarna  that  wlU  detect  that  fault. 

In  the  darhration  of  tha  aquation  of  tha  axpactad  fault  coreraga  tha  following  symbob  ara  used: 

n  b  tka  number  of  input  linaa  of  tha  circuit. 

tf  b  tha  number  of  different  poaaibb  patterns,  N  =  3*. 

Af  b  tha  total  number  of  poaaibb  faults. 

In  (13|  and  [14]  tha  aquation  for  tha  expected  fault  coaurage  B{Ci)  b  derived; 


B(Ca) 


“5(^)1  •  )■ 


(1) 


where  L  b  the  number  of  pattarna  that  have  been  applied,  and  ka  tha  k'*  alament  of  tha  datactabUlty  profile  vector  H, 

It  can  ba  shown  that  tha  axpactad  bult  covunga  E{Ct,)  b  amaU  for  circuita  with  faults  with  a  smaU  detectability  k,  i.e. 
with  faulta  which  ara  only  datactad  by  a  taw  (k)  taat-pattarna. 

Bxampb  3  shows  tha  use  of  Eq.l. 

Bsaaipfa  3 

Tha  datactabUlty  profile  of  tha  circuit  of  Figure  T  (sea  Bxampb  3)  b  H  =  |ki,ki,ks,"  -  ,hsa],  with  ki  =  1,  ks  =  S, 
he  w  T,  he  w  1,  ka  w  1,  kia  1,  kjs  =  1  and  kn  3.  The  total  number  of  diffarant  input  patterns  b  32  (N=32) 
and  there  ara  34  different  poaaibb  belts  (M— 34).  Now  tha  axpactad  fault  eovaraga  for  Afferent  test  lengths  L  can 
ba  cabnUtad  with  Eq.l.  The  ceanlt  b  shown  b  Thbb  3. 
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Tibk  1:  Th*  mpacted  fmalt  cov«n(4  B{Cl)  (or  tk«  cirenit  in  BxunpW  3  tor  diffannt  tut-lengtht  L 


L 

BiC:.) 

L 

BCCc) 

1 

0.339 

13 

0.910 

2 

0J93 

IS 

0.925 

3 

0A04 

14 

0.938 

4 

0A91 

IS 

0.948 

8 

OMl 

16 

0.987 

8 

0.730 

17 

0.964 

7 

0.768 

18 

0.970 

8 

0807 

19 

0.975 

9 

0841 

30 

0.978 

10 

0868 

38 

0890 

11 

0891 

33 

IJOQO 

Ebr  n  fonlt  covong*  of  9SX  Ifl  input  pnttoru  uo  noodod.  Fignro  8  showt  how  tha  axpactad  fault  coveraga  incraatat 
whan  tha  nnmbar  of  pattami  L  ineraaaaa. 


Fignia  8:  Tha  axpactad  fault  coraraga  E{Ci)  at  a  function  of  tha  taat-langth  L 


O 

Bacauaa  of  tha  probabiilatk  approach  of  Eq.l,  tha  axpactad  fault  covtraga  can  differ  from  tha  real  fault  coverage  (which 
can  ba  computed  through  (fault-)  almulation).  Wagner  at  al.  [U|  ahowa  that  in  moat  caaaa  the  expected  fault  coverage 
diffan  laaa  than  3.8  percent  from  tha  real  vahia. 

Implementatiom  of  Fieudorandom  Fatteni  Geaerntora 

Tha  paaudorandom  pattern  generator  (PRPG)  it  moattjr  Implamantad  uaing  a  LFSR  (Linear  Feedback  Shift  Regieter).  A 
LFSR  conaiata  of  a  atring  of  raglatan  (flip-flopa/latchaa)  and  (axcluaiva-)  OR-gataa.  Several  output  lines  of  the  registers 
are  fad  back  to  tha  input.  Tha  number  of  re^atars  and  tha  wap  tha  feedback  paths  are  impismanted,  together  with  tha 
seed  (tha  initial  contents  of  tha  registers)  datarminas  tha  length  of  tha  test  sequence  before  it  repeats.  The  length  of  a 
teat  sequence  (tha  nnmbar  of  dlffarant  patterns  that  are  generated)  can  ba  at  moat  3”  (when  tha  LFSR  has  n  registers). 

In  this  section  throe  pseudorandom  pattern  generators  an  givan,  namalp  a  general  PRPG,  a  so-called  'maximum  length* 
PRPG  and  a  *maxtmum-langth*  PRPG  Including  tha  all-taro  pattern. 

Flgun  9  showt  the  Implamantation  of  a  LFSR  with  three  ragistars  and  three  feedback  paths  (using  two  XOR-gataa). 
These  feedback  paths  determine  the  so-called  'characteristic  poipnomial*  or  'function*  of  tha  LFSR.  The  characteristic 
polpnomialof  tha  LFSR  of  Fignn  9  is  x'-bx’-bx-f  1.  Thasnp  tha  characteristic  poipnomial  of  a  LFSR  can  be  computed 
is  given  in  |9|,  (8)  and  [18|. 


Figure  9;  A  general  LFSR  with  characteristic  poipnomial  x*  -b  x’  +  x  -b  1 


When  the  Initial  contents  of  the  registete  of  Figure  9  Is  000,  then  the  contents  of  tha  ragisten  of  the  LFSR  (after  a 
dock-pelse)  will  also  ba  000.  So  the  number  of  different  patterns  produced  with  seed  000  is  1.  When  the  seed  is  100, 
four  patterns  are  generated  before  the  sequence  repeats,  nametp  100,  110,  Oil,  001,  100,  . . .. 
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Now  eoBsidar  th«  IfSR  of  FI(Bn  10. 


Fignn  10:  A  'mixlniiim  kngth*  LFSR  with  chknct«ri*tic  polynomitl  «*  +  x  -f  1 


Whxn  thx  Mxd  of  tho  LFSR  It  100,  thx  anmbor  of  difforoxt  pxttonu  thxt  xn  (•nerxtod  will  b«  7  (the  mucimum  number 
of  pxttonu  for  x  LFSR  with  throe  rofleteie),  xxmely:  100,  110,  111,  011,  101,  010,  001  ,  100,  . . ..  The  chxrxcterletic 
potyaomlxl  of  the  LFSR  It  t*  +  *  + 1. 

The  qneetloB  now  It  how  to  mxhe  x  ‘mxximam  leafth*  LFSR?  Wxsf  et  xl.  |16)  ehowe  thxt  for  x  LFSR  to  hxve 
mxxlmam  length,  the  ehxrxeterietlc  polynomlxl  ehonld  be  x  eo-cxUed  'primitive*  polynomixL  Whether  x  poiynomixl 
i’(x)  ix  primitive  exn  be  determined  by  dividing  x  polynomlxl  x'  -t- 1  by  the  (poeelble)  primitive  polynomial  F(x).  When 
the  emxUeet  integer  m  lx  eqnxl  to  2*  -  1  (when  n  ix  the  number  of  regiitere  of  P(x)),  then  the  polynomial  P(z)  ia 
primitive  (xex  xlxo  |S|). 

The  midn  dixxdvxntxge  of  x  normxl  'maximum  length*  pxeudorxndom  pattern  generator  ix  thxt  it  cannot  generate  the 
xU-iero  pattern.  The  problem  of  not  being  able  to  produce  the  xU-iero  pattern  can  be  lolved  by  adding  a  NOR-gate 
and  xn  XOR-gxtx  (xee  [S|).  Flgnie  11  ehowe  the  LFSR  of  Figure  10  changed  in  anch  way  thxt  it  producee  all  2*  patternx 
(namely  the  pxttemx  100, 110,  111,  011, 101,  010, 001,000, 100, ...  ). 


Figure  11:  LFSR  with  chxraeterixiic  polynomial  i*  4-  x  4- 1  with  the  xll-iero  pattern 


The  Incluxion  of  the  xU-ieto  pattern  coete  a  (large)  NOR-gxte  and  one  XOR-gate.  Although  it  haa  been  atated  that  a 
PRPG  ehonld  generate  all  patteme  with  equal  probability  in  order  to  calculate  the  expected  fault  coverage,  uaually  it 
will  not  be  neceaxaiy  to  generate  the  aU-xero  pattern.  It  lx  obvionx,  that  when  the  total  number  of  posaible  patterna  ia 
large  in  comparixon  with  the  text-length,  the  probability  of  generating  the  all-aero  pattern  Ix  very  amall  and  therefore 
the  hardware  to  generate  the  alLiero  pattern  will  not  be  worthwhile.  It  will  only  be  nxeful  whan  (through  aimulation} 
it  can  be  ehown  that  certain  faulte  can  only  be  detected  with  the  all-aero  atate. 


S.3  TEST  DATA  EVALUATORS 

Thix  xection  dlxcuaxee  the  implementation  altemathree  for  the  That  Data  Blvaluatore  (TDEx).  The  function  of  the  TDE 
ix  to  determine  whether  the  reeponae  of  the  CUT  to  the  input  data  ix  correct.  A  global  model  of  the  TDE  ia  ahown  in 
Figure  12. 


BCFretKt 


(aeaccf/Fau.T 


Figure  12:  Qlobel  model  of  a  TDE 


The  TDE  mnxt  eomptn  the  data  ttom  the  CUT  with  xo-caUed  reference^lata  (the  data  that  ia  known  to  be  comet). 
Thlx  can  be  done  ia  tin  wapx:  with  or  without  a  remprexeor.  (xee  Figure  lS(a)  and  (b)). 
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TIm  piDblm  with  Bom-compnMlac  TDEs  It  th»t  th«]r  SMd  a  luf*  itonc*  capacity  for  tha  nforanca  data.  Thuafora 
tha  Boa-compraaihit  TDB  k  aaldom  naad.  la  thk  papar  oaly  compiaaaiag  TDEk  will  ba  diacnaaad. 


Flfara  13:  (a)  Noa-compraatiat  TDE.  (b)  Compiaaaiaf  TDE 


Tha  foUowlaf  tabjaeta  win  ba  daaeilbad: 

1.  OVSKVISW  or  COMPRESSING  TECHNIQUES 
Tha  major  comptaaala(  tachalqaaa  ara  dlacaaaad. 

2.  CRC  CODING  THEORY 

Tha  thaoiy  of  tha  moat  coaimoaly  oaad  compraaaiag  tachniqna  (naing  CRC  coding)  ia  daacribed. 

3.  IMPLEMENTATIONS  OP  CRC  SIGNATURE  ANALYZERS 
Tha  way  CRC  aigaatara  aaalyaara  caa  ba  impkmaatad  ara  daacribad. 

4.  MASKING-CHARACTERISTICS  OF  CRC  SIGNATURE  ANALYZERS 
Tha  typaa  of  foolta  aot  datactod  (maakad)  with  tha  CRC  aigaatara  analytar  ara  lookad  at. 

Tha  aactloB  aada  with  eoacloaiona  oa  tha  anbjact  of  taat  data  anlaatoia. 

S.S.l  OVEBVIEW  or  COMPRESSING  TECHNIQUES 

la  aimoat  all  caam  tha  TDE  coaaiata  of  a  data  eompraaaor  and  a  comparator  (aaa  Fignra  13(b)).  The  data  compreaaor 
mapa  a  bag  atraam  of  data  from  tha  CUT,  lato  a  ralathraly  abort  aroid,  caOad  a  aignatura.  An  ideal  data  compreaaor 
woald  have  tha  proparty  that  a  fanlty  laput  data  atraam  will  alwaya  yiald  a  fanlty  aignatnra.  However,  no  auch  data 
compreaaor  it  la  axktaaca,  baeaoaa  hi|^  eomprataioa  rataa  caa  only  ba  achiavad  with  non  loaa-fraa  compreaaion  tachniquaa, 

i.a,  tachalqaaa  which  caanot  raprodaca  tha  origiaal  data  exactly.  Tha  aetioa  of  mapping  an  erroneone  data  etream  into 
a  correct  aigaatara  k  called  error  maiMnf  or  ah'eet'ny.  Tha  baat  ona  woald  hopa  to  gat  from  a  data  compreetor  ii  a  email 
probability  of  error  maakiag,  whkh  axpraatat  tha  qaallty  of  a  data  compreaaor. 

Tha  major  waya  of  compteming  data  ara: 

1.  Parity  ChoeUag 

A  TDB  aaiag  the  parity  checklag  method  checka  tha  parity  of  tha  data  output  atiuam  of  tha  CUT.  A  parity  chack 
frill  detect  any  fa^  produced  by  aa  odd  aumber  of  mror  bite,  to  all  elngk  bit  arrort  will  ba  datected.  Faulta  dua 
to  aa  eauB  aumber  of  error  bite  win  aot  ba  detaetad.  Tharafora  thk  compramion  mathod  haa  an  error  maaking 
probabinty  of  about  04,  which  k  not  acceptabb. 

2.  Oaaa  Cwtmting 

b  oaat  couatbg,  aa  the  aama  auggaata,  tha  data  eompraaaor  k  manly  a  conatar,  couatbg  tha  numbar  of  logical 
oaaa  b  the  data  output  atraam  of  tha  CUT.  It  k  a  ’bgt-bit  counter  (whan  (  k  tha  numbar  of  data  output  bita 
of  the  CUT).  Oaet  couatbg  wiU  detect  any  tiagh  bit  error  and  a  large  part  of  tha  multipla  bit  erron  (aea  [16]). 

3.  Tkanaltkni  Covatlag 

Ikaaaitioa  couatbg  eouata  tha  number  of  thnee  the  output  data  atnam  chtagaa  value  (from  0  ->  1  or  from  1  -r 
0).  Aa  with  oaaa  couatbg,  tha  couat  length  k  proportbnal  to  *  log  of  tha  length  of  tha  data  output  etnam  of  tha 
CUT.  It  can  be  akowa  that  a  tcaaaltbn  counter  which  k  couaUng  large  data  atnama,  wiU  have  an  error  maaking 
probabinty  of  0.5.  Tkarafon  thk  method  k  aaldom  uaad  jlj. 

4.  Cyclic  Rednndancy  Check  Coding 

Tha  cyeUe  ndundaney  check  (CRC)  techaiqua  uaaa  a  Uaaar  foadback  ahlft  ngktar  to  compraaa  the  data  of  the  CUT. 
Tha  coataata  of  tha  ngktar  depend  on  data  output  atnam  of  tha  CUT  and  tha  pravbua  contanta  of  the  ragkter. 
Tha  coatenta  that  nmaiaa  b  the  ragkter  k  the  tifnatun  and  wUl  ba  compand  with  rafannea  data.  Compnaaon 
uaiag  CRC  coding  an  very  popular,  bacauaa  of  their  almpk  implameatatbn  and  good  (emaU)  maaking  probability. 
Tha  theory  of  the  CRC  compnmbg  technique  win  ba  daacribM  mon  datalkd  in  Section  3.3.2. 

S.S.a  CRC  CODING  THEORY 

Tha  mab  purpoaa  of  a  aignatun  aaalyaar  b  to  compraaa  the  data  combg  from  tha  CUT  to  a  coda  word,  called  riynolure. 
The  compraaabn  k  baaed  on  tha  CRC  eodbg  theory.  Tha  CRC  coding  theory  tnata  atnama  of  bbary  data  aa  polynomiak 
whh  bbary  eoefflclaato.  A  bbary  data  atnam  of  t-bita  (paPiPa  •  "Pr-iPi-i,  whan  pt  k  0  or  1)  can  ba  npreaentad  aa  a 
polynomial  with  t  terma,  namely  the  polynomial  pi-i«*“*  +  Pf-a**~’  +  •  •  +  pm  -h  po  (aea  Exampk  4).  Tha  degree  of 
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th*  poijraomlal  k  tk*  krfwt  powtr  of  <  In  »  Urm  of  tko  polynominl  with  n  non-uro  coofBcient.  Only  the  coefficientt 
art  of  inteiait,  not  tha  nctnni  enlno  of  i. 

MumtfU  4 

The  Inpnt-etienm  1001011  can  be  lepraaentad  by  the  polynomial  a*  -I-  x‘  -t-  z*  1.  The  degree  of  this  polynomial 

kS. 

□ 


One  can  perfonn  arithmetk  on  the  polynomlak,  with  coefllcient  addition  and  mnitipUcation  modulo-2.  Hence  there  are 
no  caniae  dnrinf  addition,  and  when  binary  polyaomlak  are  added,  multiplied  or  divided,  the  result  is  also  a  binary 
polynomial  (sea  [9]  [S|).  Dhrklon  of  one  polynomial  by  another  produces  a  quotient  polynomial  Q[z)  and  a  remainder 
polynomial  JHn). 

Cp) 

The  remainder  JI(x)  k  often  need  as  the  ’signatara*  of  the  data  output  stream  from  the  CUT. 


S.S.S  IMPLKMXNXATIONS  Of  CRC  SIGNATURE  ANALYZERS 

In  thk  aectioa  hnpkmeatatlons  of  signature  analysers  using  the  CRC  coding  method  will  be  discussed.  There  are 
ganaraliy  two  types  of  CRC  signature  analysen,  namely: 

1.  'Oa^iapat*  Signature  Annlysert  LFSR 

When  only  one  output  of  the  CUT  k  obeerved,  a  IfSR  (Linear  Feedback  Shift  Register)  can  be  used  as  CRC 

signature  analysar. 

2.  *MnlU-lnpot*  Slgnatiira  Analysert  MISR 

The  hOSR  (Multi  Input  Signature  Register)  observes  muttlple  output  lints  of  the  CUT  at  the  same  time. 

"On^inimt”  Slsnatnra  Analyier:  LFSR 

A  LFSR  (Linear  Ibedbaek  Shift  Regkter)  coiuista  of  three  parts,  nameiy  the  register  (consisting  of  flip-flops  /  iatches), 
eselnslve-OR  gates  and  feedback  paths.  The  way  the  three  parts  of  the  LFSR  are  conflgured  determines  the  behaviour 
of  the  LFSR.  Two  of  those  variationt  will  be  described: 


1. 


LFSR  with  Dbtrlbnted  Feedback 
A  LFSR  with  distributed  feedback  k  shown  in  Figure  U. 


Figure  14:  LFSR  with  dktributed  feedback  and  dhrkor  polynomial  x*  -t-  z’  -f  1 


The  number  of  flip-flops  and  the  way  the  fsedback  lines  are  connected,  determines  the  so-called  divisor  polynomial, 
whkh  k  the  characteristic  of  the  IFSK  The  fnelicnt  of  a  IFSR  are  the  bits  (the  data)  shifted  out  of  the  LFSR 
and  the  remainder  of  a  LFSR  k  the  contents  of  the  regktete  after  the  shift  operations  (see  Exampk  S). 

The  dhrkor  polynomial  C(s)  k  determined  by  the  number  of  flip-flops  and  the  way  the  feedback  linos  are  connected 
(see  tB|  |6|). 


Fsempfe  5 

If  an  input  stream  110001001  (F(s)  w  s'  -f  s*  -t-  s  -i- 1)  k  fed  into  the  LFSR  Input  of  Figure  14,  then  the 
LFSR  comes  Into  the  states  of  Tbbk  S. 

Ibble  S;  LFSR  states  during  a  divkion 
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Tbs  dhrkor  priynomlal  k  0(s)  •  s' -t-  s*  -(■  1.  The  qnotiaat  Q(s)  (011010000  k  s*  s' -t-  z)  k  shitted  out 
cf  the  LFSR  and  Ji(s)  (the  remainder,  or  s*  s*  -f  1)  remains  in  the  regkter  alter  the  9  clod  pulsae. 

□ 


Thk  LFSR  stractiru  will  create  a  'coda  word*  (lt(s))  ae  the  remainder  alter  dividing  the  message  polynomial 
(P(s))  by  the  fhedbuck  polynomial  ((7(s)).  ii(s)  k  called  the  signsfure  of  the  data  stream  P{x).  Therefore  the 
LITO  k  called  a  rifimbm  analpssr. 


M-U 


S.  U8K  with  CoitralUwl  PMb«ck 

Tb*  IiFSR  of  Figvn  14  iiMdod  XOR  gatw  botwean  MvanI  itagM  of  tha  ahift  ragiatar.  Tha  alternative  implemen- 
UtioB  (laa  Fignn  15)  doaa  not  have  thoaa  gatea,  but  baa  only  one  XOR  gata,  at  tha  input  of  the  LFSR. 


Figure  IS:  LFSR  with  centralUad  feedback  and  diviaor  polynosiial  + 1’  +  1 

The  ’tamaindar*  (tha  value  of  the  ragiatara  after  tha  aalf  teat)  ia  not  tha  remainder  of  a  diviaion  (aa  with  tha 
diatributad  LFSR),  but  baa  tha  aama  maaking-ebaractariatica  aa  tha  aignatura  of  a  LFSR  with  diatributed  feedback. 
Tbia  Implamantatlon  can  therefore  alao  be  naad  to  generate  a  aignatura  of  an  input  data  atraam  ([IT]). 


”Multl-)aput  Signntur*  Asnlyier:  MISE. 

For  taating  a  CUT  with  multiple  outputa,  tha  circuitry  overhead  of  a  aingla  input  aignatura  analyrer  on  every  output 
would  be  high.  The  aingla  input  analyaar  could  be  multiplexed  to  the  varioua  outputa  of  the  CUT,  one  at  a  time,  and 
repeat  the  teat  aaquanca  for  each  output.  However,  a  parallel  aignatura  taating  method  uaing  a  atructure  called  a  Multiple 
Input  Signature  Ragiatar  (MISR)  (aaa  Figure  16)  ia  preferred,  becauae  tha  compreaaion  ia  dona  in  parallel  for  all  outputa 
of  tha  CUT. 


Figure  16;  A  multiple  Input  aignatura  ragiatar 


Again  the  value  of  the  ragiatara  after  the  aalf  teat  ia  called  tha  aignatura  or  the  remainder  of  tha  MISR. 

8.8.4  MASKING-CHAEACTERISTICS  OF  CRC  SIGNATURE  ANALYZERS 

Tha  main  concern  with  tha  uaa  of  aignatura  analyaera  uaing  the  CRC  coding  technique  it  the  probability  that  an  erroneout 
atraam  from  a  faulty  CUT  could  be  compraaaad  into  the  came  aignatura  aa  a  good  CUT.  Thit  ia  called  maaking  or  aliasing. 
In  tha  next  aactiOBa  tha  maaking  charactariatica  of  tha  daacribad  implementation  of  a  signature  analyser  with  a  LFSR 
and  with  a  MISR  will  be  daacribad. 

Mnnklng-characterintien  of  LFSR* 

According  to  [IT),  a  signature  analytar  with  tha  LFSR  with  cantralisad  feedback  haa  the  same  maaking  charactariatica 
aa  a  LSFR  with  distributed  faadbad. 

A  fault  in  a  CUT  can  causa  aa  error  on  tha  CUT  output  in  one  or  more  bit  positions  of  tha  output  stream.  Tha  possible 
error  patterns  can  be  treated  as  polynomials,  where  each  non-saro  coefficient  in  tha  error  polynomial  £(z)  represents  an 
error  in  tha  corresponding  bit  position  of  tha  CUT  output  straam. 

Essmpfe  I 

If  the  nlnath,  third  and  aacond  bit  of  an  output  stream  is  arronaona,  the  error  polynomial  £(zj  ia  £(z)  =  z‘+x^+i. 

a 

Pt(*)  (which  is  the  actual  output  stream  of  tha  faulty  CUT)  is;  i’c(z)  =  P(x)  +  £(z),  where  /’(z)  ia  the  output  of  a 
'orrect  CUT. 

Ezempfa  7 

If  tha  correct  CUT  data  output  P(x)  isF(z)  =  s*4-s*-t-zd-l  and  tha  error  polynomial  £(z)  ia  £(z)  =  z*  +  z’d-z 
than  tha  result  (ths  incorrect  CUT  data  output)  will  be  /*a(z)  =  z*  +  z’  -t- 1. 

a 

As  i’(x)  s  <3(z)  a  0(z)  -t-  ii(s)  and  £a(z)  =  P(s)  -f  £(z),  then  an  undetectable  error  will  occur  if  Pe{z)/0{x)  will  have 
tha  same  remaindar  J^z)  as  P(s)/0(s).  This  means  ttat  i*s(z)  =  Qe{*)  •  C(s)  +  R(x). 

This  win  be  lUnstrated  with  an  example: 


24-13 


B»*mpl€  S 

U  the  divbor  polynomial  of  the  LFSR  it  <7(s)  =  a*  +  + 1  and  the  correct  CUT  output  itream  if  P(x)  » 

X*  X*  +  X  +  1|  then  the  remainder  will  be  R{s)  =  x*  +  x^  +  1  and  Q{s)  (the  quotient  polynomial  of  the  correct 

CUT)  will  be  Q(x)  =  x*+x*+l.  But  If  the  error  polynomial  E(x)  of  the  faulty  CUTU£r(x)  = 

then  Psiz)  (the  faulty  CUT  output  etream)  ie  Pm(s)  »  x^  +  x*.  This  results  is  the  remainder  Px(x)  -  +  x^  +  1, 

which  is  the  same  polynomial  as  the  one  that  remains  In  the  LFSR  after  a  correct  CUT  output  stream  has  been 

applied. 

□ 

If  the  degree  of  the  correct  data  polynomial  is  t  —  1  (the  data  stream  has  t>bits),  then  there  are  2'  —  1  possible  error 
polynomials,  because  an  error  can  be  represented  by  a  polynomial  of  degree  t  —  1  or  less  (the  error  polynomial  £[2)  s  0 
is  eliminated).  If  C(x)  Is  of  degree  m,  then  it  has  2^***”^  —  1  non^tero  multiples  of  degree  less  than  t.  So  there  are 
2O-"*)  _  1  wrong  t-bit  streams  that  can  map  into  the  same  signature  as  the  correct  data  stream.  If  all  error  polynomials 
are  equally  likely,  then  the  probability  that  the  divisor  of  degree  m  will  not  detect  an  error  is 

jO— «)  _  1 
Pm^tkinf  —  ,1  _  I 

uid  for  lug*  ( it  moant  that 

P mmfkint  =  ^  (2) 

•o  th«  ’maaklng-probability*  can  b«  made  quit*  imaU  by  increaiing  the  degree  m  of  the  divisor  polynomial  C7(z). 

Note  that  Eq.2  ie  only  correct  when  the  error  polynomiaii  are  equally  likely. 

Maaktng*ebaraeteristlca  of  MlSRa 

It  can  be  ebowa  that  a  MISR  hae  maeking  characterittice  which  are  quite  elmllar  to  tboee  of  a  tingle  input  eiguature 
analyser  (LFSR)  ((l|,  (Sj). 

If  all  poeeible  error  polynomialt  are  equally  likely  then  the  probability  that  a  MISR  using  G{z)  as  the  divisor  wiil  not 
detect  an  error  ie 

gt*-'!  —  1  I 

Pmttkiit,  =  (If  t  =  large), 

(with  ( is  the  number  of  data  bite  that  are  collected  (or  the  number  of  clock-puleet),  and  m  la  the  number  of  regietere  of 
the  MISR).  So  the  *maeklng*probabiUty*  can  be  made  quite  email  by  increating  the  degree  m  of  the  dWieor  polynomial 

aw. 

S.a.5  DIVISOR  POLYNOMIAL  CONSIDERATIONS 

The  neefulneee  of  CRC  elgnatnre  analysert  hae  been  ehown  above.  There  remains  still  one  question:  what  divisor 
polynomial  sbonld  be  need  for  elgnatnre  aualytle?  The  maeking  probability  Pn..siF>>  »  S'"*  for  equally  likely  error 
patteme  and  long  data  etreame.  Thie  impUet  that  m  (the  degree  of  the  divleor  polynomial)  ihould  be  large  enough. 
Some  error*  can  be  dietlngulehed  (for  a  detailed  enalytit,  see  [S]),  namely: 

1.  Single  Bit  Errors 

Single  bit  errors  are  those  errors  that  affect  only  one  bit  in  the  output  stream.  These  errors  will  be  detected  by 
any  polynomial  with  two  or  more  non-sero  coefficients. 

2.  Buret  Errors 

Bunt  error*  ar*  tho**  error*  that  occur  whan  within  a  d-bit  output  stream,  at  most  d  bits  are  erroneous.  These 
errors  will  be  detected  by  a  signature  analyier  with  polynomial  z"  1,  where  m>  i. 

3.  Slngl*  Ontpat  Error* 

Single  output  errors  occur  when  only  one  input  of  the  CUT  gives  wrong  values  (and  when  the  outputs  of  the 
CUT  ai*  connected  with  a  MISR).  The  probability  that  an  single  output  error  will  be  meeked  le  the  same  as  the 
maeking  probability  for  LFSRe. 

4.  Error  CancoIUtlon  Errors 

Th«  only  kind  of  arror*  that  can  occur  in  MISR*  which  will  result  in  a  bighei  maeking  probability  are  the  error 
cancellation  errors.  But  it  can  be  ehown  that  these  errors  will  not  have  a  significant  part  in  the  complete  masking 
probability,  so  these  kind  of  errors  are  negligible. 

But  etui  the  feet  remalne  that  a  dWieor  polynomial  C(s)  will  have  a  certain  probability  that  it  will  not  detect  an  error 
polynomial  £(*)  which  le  a  multiple  of  0(x).  One  thou^t  to  deal  with  this  problem  ie  to  incorporate  a  rather  complex 
feedback  structure  bito  the  LFSR  (MISR),  on  the  leenmptlon  that  a  complex  C(*)  will  prevent  maeking  by  anything 
but  an  equally  complex  E(s].  The  Hewlett-Packard  S004A  Signature  Analyser  [18]  for  example  n*e*  a  Ifi-itage  LFSR 
with  C(x): 

G(*)  =  .“-h.*-h.V**-(-l. 

Another  example  of  polynomials  which  ar*  usad  in  the  laid  1*  th*  CCITT-16  polynomial 

G(*)  =  *•*  +  »*’  +  **  +  1, 


A 
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wkkh  I*  oMd  in  micropiocMion  (tlu  MCfitOlO  [19]  and  tka  MC6804P2  [20])  or  co-procettort  (the  MCesSSl  floating 
point  proeiaaor  [>l]). 

Tharafort  tha  onijr  ‘anaarai*  ona  can  gat  ia  that  G(s)  ahonld  ba  choaan  in  auch  way  that  no  axpactad  fault  in  the  CUT 
wU  ciaata  a  poiynomiai  that  ia  a  mnitipla  of  G(s).  A  polynomial  of  a  high  degraa  and  a  complex  feedback  itructure  U 
an  accepted  practical  mla.  By  almnlatlng  tha  clrcslt  tha  polynomial  can  ba  proved  to  be  aatiaflabla. 

4  BOUNDARY  SCAN  TEST 

The  third  phaaa  of  tha  aalf  teat  of  a  circuit  (tha  boundary  acan  teat)  taata  the  ao-called  exterior  logic.  Exterior  logic  ii 
combinational  logic,  which  ia  at  ona  aide  connected  with  logic  from  another  circuit,  and  at  tha  other  side  it  is  connected 
with  tha  (intamal)  ragistars  of  tha  circuit  (see  Figure  IT).  Since  the  exterior  logic  is  difficult  to  test,  the  exterior  logic 
should  ba  held  as  smsA  as  poaaibis. 


Whan  a  acan-path  teat  (for  tha  ragistars)  and  a  intamal  BIST  (for  tha  intamal  logic)  has  bean  applied,  the  only  com¬ 
binational  logie  that  remains  untested  it  tha  exterior  logic.  Tha  problem  of  tasting  exterior  logic  has  bean  racognissd 
by  soma  large  companiaa  (mostly  large  scale  naan  or  prodncan  of  printed  circuit  asaambllss  and  syttanu),  which  have 
formed  tha  Joint  That  Action  Group  (JTAG)  group  ia  formed  to  deal  with  this  problem. 

Tha  solution  to  tha  problem  of  not  tasting  tha  exterior  logic  la,  according  to  JTAG,  called  boundary  scan  test  (|22j). 
Tha  obiactiva  of  boundary  scan  teat  ia  to  sapamta  tha  exterior  logic  from  tha  other  logic  of  tha  circuit.  Patterns  can  be 
applied  at  tha  input  aignala  of  tha  exterior  logic,  and  tha  raanlta  can  ba  coUactad  at  tha  output  signals  of  the  exterior 
lo^.  This  Is  dona  by  conflguring  tha  ragistan  (flip-flops,  latchaa),  which  are  connactad  to  the  exterior  logic,  such,  that 
during  tha  boundary  Kan  test  tha  contents  of  those  ragistan  can  ba  controUad  by  the  boundary  scan  test  controller 
(which  is  not  part  of  tha  circuit). 

Tha  question  that  arises  now,  is  how  ahonld  tha  input  and  output  ragistan  ba  re-conflgursd  such  that  they  can  act  like 

a  shift  register  during  boundary  scan  test  phaaa,  and  that  they  an  able  to  coUact  tha  data  on  tha  input  Unas. 

a-stsa-osts-auT 


Figure  Ig;  A  boundary  scan  memory  element 


Tha  ra-conflguntion  ia  drawn  in  Flgun  18.  Than  an  tva  axtm  control  and  data  iinss: 

1.  b-scan-data-ln 

Through  this  data  line  tha  data  coming  from  tha  pnvious  boundary  scan  memory  alsmant  (from  *b-tcan-data-out*) 
(or  tha  boundary  scan  test  eontroUar)  is  given  to  tha  boundary  scan  alamant. 

2.  lwseaB^ta>ont 

This  data  Una  is  used  to  shift  the  data  out  tha  boundary  acan  memory  element,  to  tha  next  boundary  scan  element 
(or  the  boundary  scan  taat-controUsr). 

8.  b  iuaadond/hhilt 

This  control  line  datanninaa  whether  during  the  boundary  scan  test  tha  data  coming  on  the  *b-scan-datarin*  Una, 
or  tha  data  coming  from  "normal-data-in*  b  eiocksd  in  tha  ragistar.  During  normal  operation  this  Une  should 
Indicate  that  tha  data  on  tha  "normal-data-in*  Una  ahonld  ba  docked  in  tha  raster. 

4.  b-aeaB-taat 

This  control  Una  datarmlnaa  whether  it  is  a  boundary  scan  test,  or  a  normal  operation. 

5.  b-aenn-clock 

This  Una  b  used  to  clock  tha  data  in  tha  ragbtar  during  boundary  scan  taut. 
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5  CONCLUSION 

In  thin  pnpni  th*  poMibUitiM  of  BoUt-In  S«lf  IWt  hnv*  bom  txnmin*i).  For  difforant  kind*  of  logic,  different  typei  of  mU 
teeU  bwt  boon  dancribod.  For  tbn  rogiittn  the  mU  teet  in  cnllnd  ecnn-pntb  teet.  The  interior  logic  it  teeted  with  one  of 
the  deecribed  interior  logic  teete.  The  exterior  logic  ie  teeted  with  the  boundary  ecan  teet  method.  So  each  teat  takea 
care  of  of  a  epeciBc  part  of  the  circuit,  and  all  theee  teeta  together  cover  the  complete  circuit.  After  the  complete  eelf 
teat,  all  logic  hae  been  tatted,  except  the  logic  that  coatiole  the  clock.  The  extra  teat-control  hardHare  (aee  Figure  4) 
needed  to  perform  a  eelf  teet  can  be  comblaad  tor  the  eeveral  eelf  teat  technlquea.  In  that  cate  one  can  detign  a  apeclal 
BIST-ecan  element,  which  raplacee  the  regiiteri  in  the  circuit. 
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DISCUSSION 

MJacobfcn,  Ge 

Have  you  actually  implemented  your  BIT  and  if  so  wtut  results  are  available? 

Author’s  Reply 

The  research  on  the  subject  Built-In  Self  Test  was  only  a  literature  study;  there  was  no  opportunity  to  actually  design  a 
circuit  (chip)  with  BIST.  Bu:  in  practice  there  are  some  chips  which  have  a  BIST  bctlity  (for  instance  Motorola  68020) 
and  they  claim  to  cover  many  of  the  possible  faults  with  th^  BIST  circuit 


WJVIaiisel,  Ge 

Can  the  BIST  build-in-self-test  methods  be  applied  for  standard  microprocessors? 

Author’s  Reply 

The  BIST  methods  can  only  be  used  when  they  are  implemented  inside  the  chip,  so  a  special  chip  must  be  designed. 

R.Ardrcy,US 

Can  BIST  be  initiated  at  any  time  during  circuit  activity  with  retention  of  state  or  only  at  system  initializahon 
(power-up)? 

Author’s  Reply 

BIST  can  only  be  used  at  system  initialization. 
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AVIONICS  SIPIRT  STSTMiS 


Or.  Ulrich  H.  Bolsbaur 
ABG  Radar  Subdivision,  Data  Processing 
Airborne  Radar  System  Group 
Sedanstr.lO,  Post  Office  Box  1730 
D-7900  01m,  Heat  Germany 


0.  Summary 

We  present  some  experiences  and  new  ideas  on  the  expert  systems  (XS)  approach 
to  solving  problesm  of  avionics  data  processing.  We  want  to  focus  on  problms 
concerning  fighter  aircraft  and  within  these  mainly  on  radar  components. 

Avionics  expert  systems  may  be  a  development  tool,  part  of  a  ground  support 
system  or  integrated  in  a  avionics  dataprocessing  systmn.  In  the  aircraft, 
main  applications  comprise  mission  oriented  tasks  like  pilot's  associate  and 
sensor  oriented  tasks  like  navigation  or  radar. 

Areas  in  which  more  intelligent  radar  data  processing  is  needed  cMprise 
situation  awareness,  mode  selection  and  electronic  counter  counter  measures 
(8CCM),  noncooperative  target  identification  (HCI)  and  radiation  management. 

To  show  the  applicability  of  the  expert  systems  approach  to  identification 
tasks,  a  demonstration  system  for  the  recognition  of  aircrafts  from  the  tex* 
tual  description  of  a  picture  was  developed  and  tested. 


1.  Introduction 
1.1.  Expert  Systems 

Before  discussing  Avionics  XS,  we  should  state  what  an  expert  system  is  and 
when  a  software  system  does  deserve  the  name  of  an  expert  system.  Various  def> 
initions  are  prefered  depending  on  the  (local  and  disciplinary)  origin  of  the 
author  so,  e.g.  criteria  for  XS  involves  the  problem  solving  skill  and  perfor¬ 
mance  of  an  expert;  knowledge  of  one  or  several  experts;  inferential  thinking; 
knowledge  and  explicit  problem  solving  methods;  and  the  system  components  and 
capabilities  listed  below. 

We  prefer  to  say  that  an  knowledge  based  system  is  a  computer  system  that  con¬ 
tains  knowledge  about  the  problem  area  in  explicit  form  and  has  the  ability  to 
combine  this  knowledge  in  order  to  solve  problem,  and  that  an  expert  system  is 
a  knowledge  based  system  that  contains  facts  and  problem  solving  knowledge  of 
one  or  several  experts. 


In  the  following,  we  list  the  essential  and  characteristic  parts  of  an  expert 
system; 

knowledge  base 

knowledge  representation 

taxonwsy,  structural  properties 
facts,  rules 

problem  solving  knowledge 
metarules 

metaknowledge  (knowledge  about  knowledge) 
control  structures 
inference  engine 

question  solver 
truth  maintenance  system 
user  interface 

user  friendly  interface 

mouse,  windowing,  menues 
help  facilities  and  explanations 
user  model 

)cnowledge  acquisition  c^q>onent 
knowledge  editor 
truth  maintenance  system 
learning  component 
fact  learning 
structure  learning 

None  of  these  components  must  be  seen  independently,  so  e.g.  a  truth  main¬ 
tenance  system  is  on  the  first  look  part  of  the  knowledge  acquisition  com¬ 
ponent,  but  It  needs  an  inference  engine  and  meta  knowledge  and  it  is  essen¬ 
tial  for  a  learning  c<»ponent,  ^ich  may  Itself  be  seen  as  part  of  the  infer¬ 
ence  engine. 
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1.2,  Avionics  Expert  Systoes 

Application  of  expert  systeas  technology  to  avionics  software  developsMnt  has 
the  sain  goals  to  aake  avionics  data  processing  systeas  acre  'intelligent'  and 
to  aake  the  process  of  software  production  aore  efficient. 

Main  steps  on  the  way  towards  ’intelligent*  systeas  are  <  saarter  avionics 
systasu  and  sensors,  clever  reaction  to  a  hostile  enviroraient  and  gcacefull 
degradation  in  case  of  failures  for  the  idiole  systsa  and  an  optiaal  support 
for  the  pilot  and  weapons  systaa  curator.  This  iaplles  the  ability  to  process 
data  froa  different  sources  that  are  uncertain,  noisy,  inconsistent,  and  soae- 
tlsws  contradictory. 

The  ala  of  mart  efficient  software  production  is  achieved  by  the  process  of 
explicit  knowledge  engineering  and  aiodelllng,  rapid  prototyping  with  its  it¬ 
erative  cycle  of  test  and  isgirovesant  and  by  the  use  of  AI  tools  and  sathods 
such  as  systea-browsers  and  object-oriented  prograaalng. 

As  with  aost  other  expert  systeas,  avionics  applications  are  mostly  dedicated 
to  solving  routine  probleas  and  aake  routine  decisions  leaving  the  final 
decision  and  exception  handling  to  the  aan  in  the  loop. 


1.3.  Expert  Systesu  and  Related  Disciplines 
1.3.1.  Artificial  Intelligence 

ZS  are  mostly  seen  as  part  of  the  AI  technology.  In  fact,  learning  and  more 
intelligent  systeas  are  reached  by  Al-technlques .  But  we  think  that  AI  as  a 
science  is  more  related  to  analysing  or  simulating  thought  processes  with  the 
help  of  c<aqputers  than  to  the  solution  of  real-world  probleas.  Expert  systems 
is  more  a  technical  discipline  defined  by  its  methodology.  Artificial  Intelli¬ 
gence  can  be  seen  as  the  field  of  studying  problea  solving  strategies  that  can 
be  applied  idien  not  enough  problem  solving  knowledge  about  a  problea  is 
available  to  eaploy  more  powerful  problea  solving  techniques  (weak  methods, 
Newell, 1969) .  With  this  definition.  Expert  Systeas  are  located  soaewhere  be¬ 
tween  the  Artificial  Intelligence  and  the  classical  decision  support  or  opera¬ 
tions  research  approaches.  Although  there  is  no  potrerful  analytical  approach 
(such  as  e.g.  control  theory),  the  experts  problem  solving  skill  and  )cnowledge 
provides  a  proven  and  effective  solution  technique. 


1.3.2.  Conventional  Software  Systems 

The  essential  difference  of  expert  systems  to  convenional  software  are  the 
facts  that  the  knowledge  -  facts  and  problem  solving  methods  -  is  stated  ex- 
pllcitely  and  not  hidden  as  part  of  formulae,  control  structures,  data  and 
data  structure  and  that  this  knowledge  is  passed  to  the  system  by  the  expert 
and  is  filtered  by  the  programmer  or  knowledge  engineer  only  with  regard  to 
structures . 

Any  data  processing  system  is  more  or  less  Intended  to  make  routine  decisions 
or  to  support  human  decisions.  Decision  support  becoaes  aore  and  more  impor¬ 
tant  as  the  software  comes  closer  to  human  abilities  and  to  the  human  inter¬ 
face,  hence  is  closely  related  to  the  ZS  tasks. 


1.3.3.  Software  and  Knowledge  Engineering 

The  process  of  modelling  and  structuring  of  the  problem  and  its  solution  is  a 
central  feature  of  the  design  of  systems  that  work  in  such  complex  environ¬ 
ments  and  is  therefore  essential  in  the  design  of  ZS.  The  emphasis  in  building 
expert  systems  is  much  more  on  modelling  the  real  world  problem  and  the  solu¬ 
tion  process  than  on  data  and  control  and  their  resp.  flows.  One  may  say  that 
ZS  tools  provide  a  way  to  "implement  by  specification' .  Going  directly  from 
the  model  problem  to  a  high  level  solution  bypasses  the  data  processing  de¬ 
tails,  hence  concent.-ates  on  a  higher  lever  of  problem  solving.  The  difference 
to  the  programming  impleswntation  is  comparable  with  the  leap  between  the  HOL 
implementation  and  assestbly  language  progamming. 

On  the  other  side,  a  rapid-prototyped  ZS  itself  may  be  seen  as  a  model  for 
some  SW  system.  It  is  a  well  established  engineering  tradition  to  make  small 
models  in  order  to  test  great  systems  one  Intends  "o  build.  Kechanlcal  models 
have  been  build  for  ships,  dams,  aircraft  and  many  other  objects  to  assess 
their  aerodymanlcal,  mechanical  and  optical  properties.  ZS  tools  give  the  abi¬ 
lity  of  rapid  prototyping.  Hence,  one  can  make  models  of  the  final  8N  in  order 
to  test  the  behaviour  and  user  acceptance  of  the  final  SW  with  a  small  effort 
compared  to  that  one  needed  to  Implement  the  final  5N.  Where  the  time  and  slse 
constraints  do  not  allow  to  use  an  expert  system  for  a  special  application, 
the  knowledge  base  together  with  the  inference  engine  may  serve  as  a  specifi¬ 
cation  of  the  software  that  has  to  be  implemented.  Solving  a  problos  with  a 
high  level  system  also  provides  a  deeper  insight  into  the  concepts  and  connec¬ 
tions  Inherent  to  the  problem  which  may  be  transferred  to  algorithms  and  data 
structures  in  later  stages  of  the  developsnnt . 
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Figure  1 . t  Expert  syatenia  provide  a  direct  way  of  iapleaentation  by 
specification. 


2.  Application  Areas  for  Avionics  Expert  Systems 

In  the  following  we  give  an  overview  on  those  areas  of  application  in  which  XS 
may  be  used  as  part  of  a  system,  i^lications  for  avionics  expert  systems  can 
be  roughly  divided  into  two  areas t  airborne  XS  and  ground  support. 

Among  the  ground  support  XS  there  are  many  applications  that  are  not  specific 
to  avionics!  simulation,  design,  education,  logistics,  configuration,  diagno- 
sis,  maintenance  and  error  recovery.  We  leave  also  aside  all  XS  applications 
as  a  support  for  conventional  SW  develocmient  such  as  configuration  management 
and  AI  tasks  such  as  autcxnatic  programming.  Even  with  these  restrictions  there 
remain  a  lot  of  special  applications  such  as  mission  briefing  or  library 
generation. 

The  airborne  systems  may  be  divided  into  two  categories,  following  (McTigue, 
1982)!  odssion  oriented  and  sensor  oriented.  Among  the  mission  oriented  tasks 
are  A/ A  and  A/G  steering  and  weapon  launch/release  computations,  sensor 
fusion,  selection  of  best  available  data,  integrated  display  management  and 
warning  functions.  Mission  oriented  tasks  concern  the  aircraft  and  its  weapons 
or  the  pilot  and  navigator.  The  sensor  oriented  task  concern  single  sources  of 
information  like  communication,  radar,  inertial  navigation,  air  data,  and 
single  displays.  The  tasks  differ  widely  but  they  have  in  ccxamon  such  tasks  as 
source  and  filter  selection,  error  estimate  and  multi- (sub) -sensor  fusion, 
failure  detection  and  the  detection  of  spoofing  or  ^Assning. 

Graceful  degradation  is  a  point  that  is  not  special  to  a  single  system  but  is 
(or  should  te)  an  essential  attribute  of  any  AI  system.  Fallback  solutions  may 
be  implemented  explicltely  vdien  the  expert  takes  into  ccnsideration  the  possi¬ 
ble  missing  information  or  failure  modes,  or  implicitly  when  the  inference  en¬ 
gine  uses  the  knowledge  about  the  syston  states  to  provide  the  best  results 
from  the  incomplete  and  contradictory  inputs. 


We  leave  aside  all  typical  AI  tasks  such  as  pattern  and  speech  recognition  and 
understanding.  In  the  following,  avionice  applications  for  expert  systems  will 
be  ordered  in  3  groups  with  a  growing  difficulty  of  realisation!  Decision  sup¬ 
port  and  surveillance,  autonomous  sensor  oriented  decisions  and  mission  orien¬ 
ted  decisions.  An  additional  last  group  will  scotch  some  ground  based  applica¬ 
tions. 
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Figure  2.:  Intelligent  systema  provide  graceful  degradation  and  adaption  to 
changes  in  environaent  and  to  lack  of  infomation. 


2.1.  Decision  Support  Near  the  Hiiman  Interface 

Decision  support,  display  control  and  surveillance  are  aaong  the  nost  proaU.* 
sing  areas  for  avionics  expert  systems  for  the  next  few  years.  We  have  apt 
human  experts  that  can  give  their  knowledge  to  support  newcosMrs  and  to  take 
much  routine  load  from  the  skilled  colleagues.  In  this  area,  the  amount  of  in¬ 
coming  data  and  reaction  time  has  to  lie  in  the  order  of  magnitude  of  that  for 
huaian  data  processing.  The  following  tasks  also  concern  radar  systems  but  are 
not  radar  specific. 


Figure  3.t  Possible  location  for  a  display  and  decision  oriented  Avionics  ZS 


2.1.1.  Node  and  Display  Control 

Mode  selection  for  displays  is  based  on  a  lot  of  experience.  To  select  the 
contents  and  form  of  a  display  depending  on  the  whole  situation  needs  the 
assessment  of  the  situation  and  e.g.  consciousness  of  pilot's  concentration. 
Graceful  degradation  is  provided  by  bridging  gaps  in  the  incoming  data  and  de- 
cluttering  the  display  by  thoroughly  weighting  the  influences  of  a  overloaded 
display  against  the  possibility  of  cxaitting  crucial  details. 


An  lnt«lllg«nt  syst«i  should  also  handle  the  pilot's  inputs  in  a  flexible  way 
to  provide  Boam  kind  of  OWIM  (do  what  I  aean).  So,  e.g.  aabiguities  arising 
frcai  cursor  positions  that  are  not  uniguely  correlated  to  display  points  nay 
be  resolved  using  soee  knowledge  about  the  situation. 

An  expert  system  for  node  and  display  control  may  be  a  dedicated  system 
(pilot's  associate)  or  part  of  the  avionics  system  in  concern  (radar,  ESN, 
navigation,  control). 


2.1.2.  Decision  Support 

An  Expert  system  can  give  direct  decision  support  for  the  pilot  (and  eventual¬ 
ly  the  NSO).  This  can  be  done  by  proposing  the  best  decision  to  the  pilot  or 
by  showing  those  facts  that  are  needed  to  make  a  decision.  An  expert  syst«B 
can  combine  a  lot  of  facts,  gathered  over  the  time  of  the  ^ole  mission  or  re¬ 
quested  from  other  sources.  It  may  select  the  best  decision  or  condense  the 
facts  to  an  aisoimt  that  can  be  displayed  in  an  ergonomic  way  in  a  combat 
situation . 

Decision  support  comprises  warning  and  notifying  the  pilot  on  situation 
changes.  This  becomes  flftost  important  when  the  attention  is  distracted  in  cri¬ 
tical  situations  or  in  the  course  of  routine  surveillance  tasks  (e.g.  in  a 
Combat  Air  Patrol).  Such  decision  supporting  systesis  need  to  be  aware  of  the 
situation  in  order  to  assess  the  iBg>ortance  of  incoedng  observations. 


2.1.3.  Situation  Dependent  Briefing 

Crew  briefing  is  essential  for  the  success  of  the  idiole  mission  of  a  fighter 
A/C,  but  is  limited  by  human  ability  to  memorize  facts.  Too  great  an  amount  of 
details  and  facts  that  are  not  likely  to  be  needed  may  confuse  the  crew  and 
degrade  their  ability  to  remember  the  essential  things.  An  ES  may  brief  the 
crew  only  on  those  facts  that  are  important  just  now,  depending  on  time,  loca¬ 
tion  and  tactical  situation.  ("By  the  way,  ..  ”) 


2.1.4.  Monitoring  and  Surveillance 

Maintenance  support  and  testing  is  mostly  based  on  heuristics  since  complete 
testing  of  all  possible  constellations  and  inputs  is  not  possible  in  a  complex 
system.  Build  In  Test  (BIT)  for  isolated  systems  may  lead  to  a  failure  and 
fault  isolation  in  the  system.  This  may  be  performed  by  an  expert  system  and 
an  intelligent  BIT  may  not  only  detect  and  locate  failures  on  the  fly  but  also 
estimate  the  Impact  and  consequences  and  provide  graceful  degradation  by 
changing  configurations  or  calling  for  adequate  countermeasures.  This  may  be 
done  by  an  autonomous  decision  or  by  giving  an  adequate  advice  to  the  pilot. 

The  surveillance  function  also  coo^rises  the  tasks  of  fuel  and  coolant  status 
control .  The  controlling  system  has  to  decide  from  the  overall  situation 
Aether  a  shortage  may  occur  or  is  critical  and  whether  the  shortage  is  impor¬ 
tant  enough  to  notify  it  to  the  pilot  thereby  possible  distracting  his  atten¬ 
tion  from  more  important  observations. 

Medical  surveillance  is  another  application  that  may  neccessitate  expert  sys- 
tesis  application.  Medical  systems  have  been  among  the  first  expert  systems. 
Since  man  is  not  fairly  represented  by  technical  or  mathematical  models,  heu¬ 
ristics  play  an  imortant  role  in  medicine.  Medical  surveillance  in  avionics 
systmas  may  comprise  long  term  surveillance  in  order  to  detect  when  the  crew 
is  getting  unconcious,  becoming  overworked  or  is  hast  lost  the  orientation.  It 
will  also  comprise  short  term  manoever  surveillance  e.g.  in  high-g  situations 
where  the  consequences  may  affect  the  mission. 


2.2.  Auton<MBOus  Decisions  for  Radar  Components 

Me  want  to  discuss  nose  radar  oriented  tasks  as  an  example  for  the  many 
sensors  that  are  on  board  of  a  modem  aircraft  (navigation,  infra  red  sensors, 
air  data,  altimeter).  Such  an  XS  may  either  be  a  separate  dedicated  system  or 
be  part  of  the  radar  system  (e.g.  the  radar  data  processor).  A  possible  con¬ 
figuration  is  given  in  figure  4 . 


Many  tasks  occur  in  parallel  also  in  electronic  warfare  co8g>onents.  ESN  (Elec¬ 
tronic  Support  Measures)  tasks  are  similiar  to  those  of  radar  and  other  sen¬ 
sors  and  will  be  omitted  here.  ECM  (Electronic  Counter  Measures)  emission 
(e.g.  jamming)  especially  needs  clever  and  tricky  reactions  and  will  be  trea¬ 
ted  in  brief  in  the  mission  oriented  section  about  self -protection.  The  coop¬ 
eration  of  radar  and  ESN/ECN  exponents  is  a  mission  oriented  task  that  con¬ 
cerns  the  whole  weapon  system  and  will  hence  also  be  treated  in  the  subsequent 
section . 
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Figure  4.:  Poseibie  location  for  a  radar  oriented  XS.  The  connections  to  the 
avionics,  attack  and  defensive  aids  subsysten  busses  would  provide  the 
possibility  to  handle  also  mlaslon  orlentd  tasks. 


2.2.1  Mode  Selection 

Modern  sensors  such  as  airborne  radars  provide  a  lot  of  modes,  sub-modes  and 
par^uneter  settings  that  can  be  selected  on  flight  to  achieve  maximum  perfom^- 
ance  and  mission  success.  The  optimal  mode  depends  on  external  data,  pilots 
intention  and  mission  aim  and  parameter  selection  requires  experience  and 
knowledge  about  the  system's  functions.  Expert  systems  may  support  the  pilot 
or  weapons  system  operator  (navigator)  in  their  task  of  selecting  the  most 
appropriate  mode  and  the  best  parameters  for  the  radar  system. 
The  task  is  to  select  the  radar  mode,  radar  parameters  such  as  beam  splitting 
beam  shape  and  width  scan  pattern,  width,  speed,  pulse  width  and  pulse  rate, 
RF  and  frequency  agility,  and  the  power  on  and  off  targets  and  the  false  alarm 
cstes  and  thresholds.  The  selection  is  based  on  radar  information  such  as 
track  histories,  actual  signal  noise  and  false  alarm  rates,  on  avionics  infor¬ 
mation  such  as  ownship  motion  and  manoever,  weapon  mode  (gun,  missiles,  bomb 
guidance),  and  on  ECM  activities.  The  overall  tactical  situation  of  own  and 
hostile  SAM  and  troop  deployment  and  the  airborne  enemy  and  own  forces  deploy¬ 
ment,  the  position  of  the  wingman,  the  type  of  the  mission  and  the  weapon  and 
fuel  load  will  also  influence  the  optimal  radar  mode. 

A  mode  selecting  system  needs  knowledge  about  the  interpretation  of  track  his¬ 
tory,  noise,  jam  and  tactical  situation.  It  must  be  able  to  assess  the  detec¬ 
tion  probabilities  as  a  function  of  radar  mode,  beam  splitting,  shape  and 
width,  scan  pattern,  width, and  speed,  pulse  width  and  pulse  rate.  The  systra 
must  weigh  up  the  neccessity  of  accurate  measurement  against  that  of  extensive 
information  gathering  and  the  neccessity  of  accurate  tracking  hostile  targets 
against  the  disadvantage  of  being  detected. 


2.2.2.  Intelligent  Tracking 

A  system  for  filter  control  may  assess  track,  plot  and  target  noise  and  syste¬ 
matic  deviations  (error,  manoevers,  ECM)  to  supervise  and  control  filter 
gains,  adapt  them  to  the  external  noise,  and  eventually  reset  Kalman  filters. 
Plausibility  control  may  detect  manoevers,  ECCM,  and  multi-target  situations. 
Clever  track  file  handling  comprises  criteria  for  the  initiation  and  deletion 
of  tracks  and  a  priorlsation  logic.  The  insertion  of  tracks  from  other  sensors 
as  well  as  intelligent  decision  for  plot-track  correlation  in  many-to-many 
situations  need  the  knowledge  about  manoeverability,  tactics,  own  sensors 's 
accuracy,  and  track-history  interpretation.  A  grovnd  based  expert  system  con¬ 
trolling  Kalman  filters  for  tracking  has  been  tested  successfully. 


2.2.3.  Priorlsation 

The  priorlsation  and  grouping  of  targets  (a/c,  ground  sites,  tanks)  according 
to  their  importance  as  a  threat  and  as  a  potential  target  is  primarily  based 
on  the  Inverse  Time  To  Go,  l.e.  the  quotient  of  range-rate  and  range.  Other 
criteria  may  be  target  features  euch  es  aanoe/era,  flight  direction,  friend 
/foe  classification  and  the  target's  weapon  isode  as  seen  frosi  the  radar  warn¬ 
ing  reciever.  Also  the  available  weapon  and  fuel  load  and  the  mission  type  of 
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thtt  ownship  aa  well  as  tha  ovarall  tactical  situation  detenninad  by  the  da> 
ploynant  of  own  and  hoatila  aircraft  and  SAM  eitaa  hava  to  be  taken  into  con> 
aidaration. 

An  axanpla  for  a  prioritation  that  provides  good  situation  avaranaaa  and  opti> 
»al  opportunltiaa  for  %faapon  daploynant  is  given  in  figure  S. 


frisnd 


B 


priority  from  ITTQ  R/R 


priority  from 


titustion  sttossmont 


Figure  S.t  Intelligent  priorisation  involves  situation  assessment. 


2.2.4.  BCCN 

To  counter  hostile  countermeasures  r^eeds  cleverness  in  order  to  cope  with  the 
game  theoretic  situation  that  the  enemy  also  reacts  to  your  reactions.  He  may 
foresee  your  reaction  or  may  even  force  a  special  countermeasure  reaction  that 
has  advantages  for  himaelf .  The  reaction  of  a  countermeasure  or  coiinter' 
countermeasure  system  should  take  into  account  all  relevant  past  events,  espe> 
dally  on  the  hostile  reactions  to  own  measures,  as  well  as  the  own  and  hos¬ 
tile  intentions. 

Plausibility  control  of  incoming  data  and  results  and  the  fusion  of  several 
independent  sources  is  a  good  form  of  countering  countermeasures  and  it  also 
provides  the  system  with  the  possibility  to  degrade  gracefully  by  leaving  away 
suspicious  and  possibly  misleading  data. 


2.2.5.  Kulti  Sensor  Fusion 

Multi  sensor  fusion  describes  the  task  to  combine  incoming  data  fr«R  several 
sources  such  as  BSK,  BCCN,  FLIR,  IFF,  etc.  The  idea  is  to  achieve  synergetic 
enhancment  of  the  heterogeneous  sources  of  information,  but  problems  arise 
since  the  data  may  be  inaccurate,  inexact,  vague,  incoo^rable  (e.g.  different 
physical  parameters),  or  even  contradictory.  Multi  sensor  fusion  may  be  used 
for  tracking,  identification  and  navigation  and  it  is  located  somewhere  be¬ 
tween  sensor  and  mission  oriented  tasks  since  it  may  involve  a  lot  of  sensors. 


2.2.6.  Identification 

Identification  is  the  task  of  correlating  an  object  to  one  of  several  classes 
based  on  observations.  It  seems  a  simple  task  that  can  be  performed  by  any 
intelligent  creature  but  identification  is  not  easy  to  ix^lement  in  a  data 
processing  system  since  data  may  be  incomplete,  inaccurate  or  contradictory. 
Non  Cooperative  identification  (Target  Recognition}  describes  the  task  to 
identify  an  object  (e.g.  an  aircraft)  based  on  the  informations  that  are 
available  from  the  aircraft's  sensors.  Its  combination  with  cooperative  iden¬ 
tification  (secondary  radar)  makes  the  decision  more  secure  but  much  more  com¬ 
plicated  . 
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Identification  and  claaaification  ia  allways  basad  on  hauristics,  even  if 
there  is  soae  Bathenatical  theory  used  to  transform  the  heuristics  to  numeri¬ 
cal  algorithms.  The  basis  for  the  analytical  (nearest  neighbour,  linear  or 
polynosdal  classifiers,  cutting  planes),  stochastc  (Bayes)  or  optimisation 
(sequential  decisions)  methods  is  allways  the  heuristic  that  assumes  that  this 
approach  gives  "best*  classification.  The  selection  os  the  method,  of  error 
and  convergence  factors,  optimality  criteria  and  template  size  is  only  based 
on  experience.  Heuristic  programming  seems  to  be  the  best  way  to  accomplish 
identification  tasks.  While  analytical  siethods  are  rather  inflexible  assuming 
a  fixed  set  of  incoming  data,  the  stochastic  optimisation  approaches  are  very 
complex,  hence  time-consuming.  Classification  algorithsis  need  a  lot  of  data  in 
the  learning  phase  since  they  lack  the  ability  to  abstract  and  to  generalise. 
Since  expert  systems  Involve  concepts  and  notations  used  by  men,  they  provide 
a  more  flexible  access  to  the  design  of  identification  systMis.  This  will  be 
discussed  further  in  the  chapter  on  the  DAVID  identification  system. 


2.3.  Mission  Oriented  Decisions  in  the  Weapons  System 

Mission  oriented  tasks  involving  optimal  behaviour  in  game  theoretic  situa¬ 
tions,  weapon  deployment,  and  automatic  pilot  may  lie  in  the  far  future. 
Nevertheless  there  are  a  lot  of  applications  of  heuristic  programming  that 
seem  to  be  possible  in  the  near  future  and  we  want  to  scetch  some  of  them. 


2.3.1.  Manoever  Oriented  Tasks 

Manoever  oriented  tasks  comprise  short-term  decisions  in  manoevering  such  as 
high-g-avoidance,  automatical  steering,  or  variable  sweep  wing  control  for 
amnoevers.  On  longer  terms  %«e  have  smart  terrain  following  and  terrain  contour 
masking,  combat  manoevers  in  Air-to-Air  and  Air-to-Oround  (e.g.  countering  SAM 
sites),  tactical  sminoevers  for  threat  avoidance,  sianoevers  for  optimal  sensor 
accuracy  commanded  by  radar  components  (ELS,  passive  tracking)  or  manoevers 
for  weapon  deployment. 


2.3.2.  Electronic  Warfare 

Some  of  the  load  of  coordinating  several  ESM  and  BCM  systems  and  i#eapons  can 
be  taken  off  from  the  pilot.  Optimal  balancing  of  RF  self  protection  with  self 
protect  weapon  delivery  involving  power  management,  HOJ  (home  on  jam)  avoid¬ 
ance,  frequency  management  and  multi  a/c  emission  control  could  be  performed 
by  an  expert  system. 


2.4.  Ground  Support 

Ground  support  will  be  among  the  first  aplication  areas  for  avionics  expert 
systems.  Since  many  tasks  such  as  maintenance  or  configuration  are  not  speci¬ 
fic  for  this  application  area,  we  will  omit  them  at  all.  We  will  sketch  in 
brief  those  applications  that  are  typical  to  avionics. 


2.4.1.  Mission  Preparation  and  Briefing 

Expert  systems  for  mission  planning  comprise  Smart  Terrain  Following  and  Ter¬ 
rain  Contour  Masking  planning,  and  fighter  deployment  and  schedule,  e.g.  to 
achieve  best  radar  coverage  for  a  Combat  Air  Patrol.  Data  fusion  to  the  es¬ 
sential  informations  is  needed  for  the  crew  briefing  as  well  as  for  the  brief¬ 
ing  the  on-mission-brief Ing-XS  discussed  above  and  for  the  debriefing  and 
post-mission-analysis . 


2.4.2.  Ground  Programming  Support 

Ground  programming  support  comprises  the  generation,  test  and  modification  of 
emitter  libraries  for  ESN,  BCM,  and  BCCM;  of  parameter  libraries  for  sensors, 
electronic  warfare  and  weapon  ccxnponents;  and  of  identification  lists,  tem¬ 
plates,  and  classification  parameters  for  Identification  tasks.  Problons  aris¬ 
ing  for  example  from  ambiguities  in  emitter  libraries  are  at  the  moment  han¬ 
dled  by  human  experts  but  there  exist  no  algorithmic  approach.  This  indicates 
that  these  problems  are  a  suitable  application  area  for  expert  system  altough 
today's  expert  system  shells  and  tools  are  not  able  to  handle  the  cosq)lex 
notations  needed  to  handle  overlapping  in  a  multidimensional  parameter  space. 

Programming  the  knowledge  base  of  an  airborne  expert  systeM  can  be  seen  as 
part  of  ground  programming  support.  On  the  first  look,  it  seems  siuch  more  dif¬ 
ficult  to  program  an  XS  than  to  generate  a  simple  parameter  list  such  as  the 
emitter  or  identification  libraries  mentioned  above.  But  we  have  to  consider 
that  there  is  much  more  ability  to  dissolve  ambiguities  in  a  knowledge  based 
system  than  in  a  primitive  system  working  on  a  single  parameter  list  and  that 
libraries  used  e.g.  for  search  regime  determination  and  esiltter  identification 
for  RWRs  or  ARMS  have  a  s»re  complicated  structure  and  contain  more  "knowl¬ 
edge”  (implicitly)  than  many  of  the  expert  systems  known  from  the  Al-litera- 
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tura.  Fron  this  It  saans  plausibla  that  a  system  to  writs  a  rule>basa  for  an 
XS  is  not  more  difficult  to  develop  than  a  systems  that  automatically  gener¬ 
ates  and  compiles  a  parameter  list  with  the  same  performance. 


3.  Problems  in  Applying  Avionics  Expert  Systems 

The  main  obstacles  hindering  expert  systems  from  a  widely  accepted  use  in 
avionics  systems  are  their  lack  of  real-time  capabilltiy  and  the  problem  that 
expert  systems  seem  to  be  non-determlnlatlc  and  non-verlfyable. 


3.1.  Real  Time  Expert  System 

The  following  aspects  make  up  the  ‘real-time*  capabilities  of  a  computer  sys¬ 
tem,  hence  determine  Its  useabllity  In  airborne  applications! 

-  fast  (avarage  raaponsa  time) 

-  guaranteed  response  time 

-  guaranteed  handling  of  all  Incoming  Information 

Restrictions  regarding  the  average  response  time  may  be  overcome  by  Increased 
HW  spe«Kl  and/or  by  massive  parallelism  idtlch  is  easier  Implemented  in  knowl¬ 
edge  based  systems  then  In  conventional  software  systems.  Airborne  XS  proces¬ 
sors  may  be  MIL  versions  of  commercial  systems  such  as  the  MIL  version  of  the 
TI  explorer,  SUM  3/50  (ARX  3/50),  IBM  PC/AT  (TAC-PC)  or  the  DEC  MICROVAX  II 
(MIL  VAX  II);  ruggedlsed  comswrclal  systesu;  or  dedicated  systems  based  on 
transputer  arrays  or  sUcroprocessors  (Conner, 1987 ) . 

Guaranteed  response  time  and  the  guaranteed  handling  of  all  Incoming  informa¬ 
tion  Is  a  problem  of  any  higher  order  language,  it  may  be  overcome  by  Al-lan- 
guage  with  the  capability  of  handling  Interrupts  and  timers.  An  Integration  of 
Interrupt  handling  Into  a  AI  systems  would  be  a  task  that  only  concerns  the 
operating  system.  One  should  keep  in  mind  that  with  such  time  varying  fact 
bases,  PROgrammlng  In  LOGIC  will  no  longer  be  pure  logic  and  the  behaviour  of 
such  systems  must  bo  testet  very  thoroughly. 

Guaranteed  response  time  might  be  Integrated  Into  the  language,  for  exasgtle  by 
a  way  to  tell  PROLOG  not  to  take  more  than  a  given  amount  of  time  for  a  spe¬ 
cial  task.  For  example,  a  Real-Tlme-PROLOG  expression  like 
R  I-  ((  PI  (tl),  P2  (t2)  )(t3)  ;  P3(t4)  )(t5). 

might  say  that  R  Is  true  If  PI  and  P2  can  be  proven  in  time  t3,  while  giving 
PI  not  more  than  tl  and  P2  not  more  than  t2  time,  or  If  P3  can  bo  proven  In  a 
time  of  t4  while  taking  no  more  time  than  tS  for  considering  this  statement 
for  R.  Rote  that  the  time  given  to  prove  a  statement  (e.g.  P2)  Is  given  by  the 
minimum  of  the  constraint  stated  explicitly  (l.e.  t2)  and  the  time  left  from 
higher  order  constraints  (l.e.  t3  -  tl'  where  tl’ls  the  time  needed  to  prove 
PI).  In  situations  where  nesting.  Iteration  or  recursion  may  occur,  precau¬ 
tions  oust  be  taken  so  that  searching  time  Is  not  spent  on  the  lowest  level  or 
the  first  goals  while  leaving  no  time  for  the  recursion  to  come  back.  This  may 
be  achieved  by  making  the  maximum  admissible  time  an  explicit  function  of  the 
time  left  over  for  the  calling  predicate.  In  our  example,  the  formula  could 
then  read  R(t)i-  ...  fdiere  t5  «  t,  and  tl,..t4  are  functions  of  t,  e.g.  t4  • 
t/2,  t3  -  2t/3,  tl  -  t2  -  t/2. 


3.2.  Proving  Expert  Systems 

It  Is  often  said  that  Al-systems  are  not  deterministic  since  the  knowledge 
base  does  not  determine  the  behaviour.  The  same  may  be  said  about  classical 
real  time  software  In  connection  with  the  runtime  system  and  it  is  clear  that 
an  expert  system  can  only  be  verified  In  connection  with  Its  Inference  engine. 
Although  XS  are  not  easy  to  verify,  they  may  be  more  easily  validated  since 
they  provide  a  more  direct  connection  between  the  problem  solving  knowledge 
(specification)  and  the  Implementation.  The  problem  of  testing  an  XS,  l.e. 
controlling  whether  It  provides  the  correct  answer.  Is  critical  In  situation 
where  no  one  knows  which  answer  Is  the  right  one.  The  problem  of  responsi¬ 
bility  for  XS  decisions  In  critical  situations  (Including  weapon  deployment) 
Is  as  critical  as  the  responsibility  for  classical  program's  decisions  and 
aircraft  craw  decisions. 

Standards  for  software  development  such  as  DOD-STD  2167  or  AQAP  13  may  be 
transferred  to  the  knowledge  engineering  and  XS  developawnt  process.  Maybe  a 
validated  and  standardised  XS-shell  or  toolbox  will  help  to  make  software 
development  for  complex  systems  safer  and  cheaper  and  will  significantly  de- 
crasa  modification  and  maintenance  costs. 
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4.  The  OAVZO  Expert  Syatan 

To  demonstrate  the  applicability  of  the  expert  system  technology  to  avionics 
tasks,  a  demonstration  system  for  the  visual  Identification  of  coad>at  aircraft 
(Demonstrator  for  Aircraft  Visual  IDentif ication )  was  developed.  The  task  was 
to  identify  about  100  aircraft  types  by  means  of  the  textual  description  of  a 
single  picture.  After  a  time  of  about  6  month  of  knowledge  acquisition  and 
structuring,  system  design  and  prototyping,  a  system  that  could  identify  25 
fighters  and  attack  aircraft  using  about  100  rules  was  impl^sented .  The  nuild>er 
of  aircraft  in  the  final  DAVID  system  will  be  bounded  only  by  the  user 
supplied  data. 


4.1.  Task  and  System  Design 

DAVID  demonstrates  the  applicability  of  reasoning  under  uncertainty,  using 
fuzzy  logics  and  uncertainty  modelling.  Its  tasks  parallel  to  some  amount  the 
tasks  that  have  to  be  accomplished  by  a  NCi-'Siodule  as  described  above,  visual 
Identification  was  chosen  since  the  system  was  intended  as  a  demonstration 
system  and  dedicated  to  men  whos^  most  important  sensor  is  the  eye,  not  to 
radar.  We  also  wanted  to  have  a  proven  expert  and  to  see  in  case  of  a  wrong 
decision  whether  the  reason  for  a  failure  was  inherent  to  the  system  or  caused 
by  data  that  were  either  wrong  or  insufficient  for  an  identification. 

This  controllability  vras  eased  by  a  textual  interface  using  a  menue  of  poa- 
slble  answers  (in  forthcoming  phases  supported  by  graphical  output),  so  no 
tasks  of  pattern  recognition,  image  recognition  or  picture  analysis  had  to  be 
performed  by  the  system.  This  was  also  selected  sice  a  menue-based  textual 
interface  allows  to  replay  session  dialogues  and  hence  to  control  the  systems 
decisions  and  to  assess  its  performance  by  comparing  them  to  the  ability  of  a 
human  observer  working  with  the  same  data. 

The  target  classes  of  the  identification  process  were  the  types  of  the  air- 
craft,  so  we  had  sharp  (non-fuzzy)  man-made  classes,  while  other  classes  and 
notations  used  in  the  process  of  identification  were  fuzzy.  Especially  in  com¬ 
bination  with  the  human  obseirver  there  was  the  problem  that  in  most  attributes 
we  had  a  continuous  transition  between  several  values  of  the  attributes  rather 
than  several  well  distinguished  values. 


4.2.  Knowledge  and  System  Description 

4.2.1.  Knowledge  Acquisition  and  Representation 

For  the  knowledge  acquisition,  structuring  and  representation  adapted  a 
phased  approach  propose  by  Harmon  and  King  (1966). 

In  the  orientation  and  problem  definition  phases,  requirements  were  collected 
and  after  Identifying  an  appropriate  expert  and  the  first  discussions  we  de¬ 
rived  a  rough  concept  of  the  domain  and  the  problem  space  and  a  project  plan 
for  the  next  development  phases.  In  the  analysis  phase  the  collection,  analy¬ 
sis,  and  structuring  of  the  concepts  and  terms  of  the  expert  and  of  the  user 
led  to  a  overall  system  design. 

From  the  beginning,  the  development  was  intended  to  have  two  major  cycles t  a 
small  prototype  using  a  PC-tool  and  a  stable  system  implemented  on  a  DEC  VAX. 
Both  systems  had  to  run  through  the  phases  of  design,  implmentation  and  the 
loop  of  testing  and  improvement. 

The  Identification  knowledge  and  problem  solving  methods  were  gathered  from 
various  discussions  with  the  expert.  The  formal  expert  interviews  in  the  pro¬ 
cess  of  knowledge  aquisition  and  -analysis  could  be  kept  at  a  small  asK^ut 
since  the  expert  ki\owledge  was  important  mainly  for  the  procedures  and  approa¬ 
ches  while  Biost  of  the  fact  knowledge  on  the  different  aircrafts  could  be 
taken  from  the  literature.  Nevertheless,  the  system  was  discussed  with  the  ex¬ 
perts  in  all  stages  in  order  to  stay  on  the  relevant  attributes  and  with  the 
best  problem  solving  behaviour.  Any  discussion  round  in  the  design,  develop¬ 
ment  and  test  phase  necessitated  some  rewriting  of  the  rules. 

One  of  the  best  tools  was  the  graphic  representation  of  all  relevant  objects 
and  relations  (semantic  net)  vdiich  gave  a  good  basis  for  the  discussion  with 
the  expert. 


4.2.2.  The  Representation  of  the  Pact  Knowledge 

The  experts  knowledge  contains  much  more  information  and  structure  than  a 
simple  list  of  attributes  or  a  set  of  relations  or  the  Bii^»Ie  "If  air-intake 
is  large  and  the  aircraft  has  variable  wing  and  twin  fin  it's  a  P-14  Tomcat” 
explanations  given  by  the  expert.  Expert  identification  is  to  a  great  amount 
based  on  a  model  ol  the  aircraft  and  on  technical  knowledge.  The  connections 
between  manoevrability,  fins,  power,  and  air-intakes  are  present  in  this 
)cnowledge  as  well  as  the  typical  properies  of  variable  geometry  wings  and  a 
model  of  the  aircraft  that  allows  him  to  judge  %diether  twin  fins  may  be  hidden 
by  the  fuselage  on  that  special  picture. 


Part  of  the  seioantic  net  for  aircraft  identification  compiled  in  the  courae  of 
knowledge  acquisition  is  given  In  figure  6. 
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figure  6 . :  Some  of  the  notations  and  connections  relevant  for  aircraft 
Identification . 


The  frame-like  hierarchical  object  structure  of  the  aircraft  identification 
given  in  figure  7  is  much  closer  to  the  implementation  than  the  8emant5c  net. 


4.2.3.  Problems  Identified 

In  the  course  of  the  knowledge  aquisition  and  -analysis  some  problems  in  re¬ 
presenting  the  relevant  knowledge  occured  which  we  want  to  scotch  in  brief. 

It  is  very  important  to  distiguish  between  hidden,  concealed,  absent,  not 
identifiable,  and  not  describable  attributes.  For  example  the  fact  that  the 
air-intake  is  hidden  by  the  wings  brings  more  information  than  e.g.  the  fact 
that  the  air-intake  is  round,  but  the  first  information  .’'.s  more  difficult  to 
represent  since  it  strongly  depends  on  the  observers  aspect. 

The  difference  between  fixed  and  variable  geometry  wings  can  be  seen  by  an 
observer.  Here,  a  helping  facility  and  metarules  are  important.  Fixed  geometry 
is  easy  to  judge  in  case  of  a  delta  wing,  but  in  the  case  of  swept  wings  dif¬ 
ficulties  arise.  Depending  on  the  geometry  at  the  time  of  observation,  varia¬ 
ble  geometry  can  be  judged  from  sharp  bends,  a  broad  shoulder  in  combination 
with  swept  or  straight  wings,  or  a  delta  like  wing  shape  formed  by  aileron  and 
tailplane. 

The  notations,  concepts,  and  terms  differed  widely  between  the  experts  and  the 
users  and  among  several  users.  In  our  first  system  with  small  menue,  almost 
any  of  the  possible  answers  for  the  F-4F'8  air  intake  form  and  wing  shape  oc¬ 
cured.  This  was  overcome  by  adding  special  values  in  the  menue,  separating 
user's  and  expert's  notations,  and  implicitly  allowing  fussyness  (round-oval- 
. . . ) .  The  notations  of  the  expert  and  the  user  were  connected  via  dedicated 
rules  that  gave  plausibilities  e.g.  for  a  swept  wing  when  the  user  selected  a 
straight  wing  or  vice  versa. 
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Figure  7.i  Hierarchical  object  structure  used  for  DAVID.  For  the  attributes 
with  a  the  user  input  notation  and  system  notation  are  separated. 


4.2.4.  Problem  Solving  Knowledge 

Iff  after  the  consultation^  one  asks  an  expert  how  he  got  his  results,  the 
answer  may  have  the  form  "if  the  aircraft  has  a  V-shaped  twin  fin  and  if  air- 
intake  is  round  and  underfuselage  then  it's  a  F-18  Hornet".  A  set  of  such 
rules  will  never  build  up  an  adequate  identification  system.  On  the  one  side 
it  lacks  knowledge  as  discussed  above  an  one  would  need  10  to  20  rules  per 
aircraft.  On  the  other  side,  the  dialogue  between  the  user  and  the  expert 
(-system)  must  first  concentrate  on  rather  general  properties.  The  user  will 
not  accept  30  questions  on  special  attributes  that  must  be  answered  mostly 
with  "no"  or  "not  applicable".  The  Expert  system  must  have  some  structure  and 
control  to  run  an  intelligent  dialogue. 

Some  of  the  identified  techniques  are  listed  below: 

a)  Heuristic  of  successive  refinement 

The  expert  looks  at  the  parts  of  the  aircraft  to  get  an  impression  ad  a  pre¬ 
selection  of  the  type.  Host  times,  the  standard  parts  with  their  properties 
are  asked  first,  for  example  according  to  the  following  Mstt 

-  wing  assembly 

-  tail  unit 

-  propulsion,  engine,  air  intake  and  jet 

-  airframe,  fuselage 

after  this,  special  parts  such  as  canards,  antennas  and  fuel,  and  electronics 
pods  and  weapon  load  are  asked  for.  Another  sequence  is  given  by  the  "WBTFUR” 
Hinge  -  Engine  -  Tail  unit  -  Fuselage  -  Undercarr.' age  -  Radiator  mnononics 
(Hood, 1982) . 

b)  Exclusion  and  confirmation  by  means  of  special  attributes. 

The  attributes  asked  for  according  to  the  a-priori  knowledge  (when  the  user 
describes  a  fighter  aircraft  he  has  seen,  in  Germany  in  most  cases  it  may  be  a 
F-4F)  and  on  the  a-posteriori  information  from  the  questions  before. 


c)  "what  catches  the  eye" 

The  expert  lets  the  user  describe  sone  properties  of  the  aircraft.  SonetiMS 
this  is  initiated  by  the  user  %dio  starts  with  a  question  for  an  aircraft  with 
some  special  property.  The  implementation  of  this  technique  is  rather  diffi¬ 
cult  since  a  free  textual  input  from  the  user  requires  some  association  logic, 
while  a  text  or  graphics  menus  would  propose  much  more  than  the  7  items  a 
human  observer  can  deal  with. 

d)  staged  and  switching  approach 

Experts  have  the  ability  to  combine  several  problem  solving  paradigms  to  get 
optimal  results.  In  reality,  the  identification  process  c^nbined  the  three 
methods  listed  above  by  switching  to  the  most  appropriate  one. 


4.2.5.  Concepts  of  Uncertainty 

The  expert  does  not  explicitly  think  in  uncertainties.  Hence,  it  is  quite 
difficult  to  determine  «rhich  uncertainty  representation  is  the  most  appropri¬ 
ate  one.  The  crucial  test  for  this  must  be  the  behaviour  of  the  resulting 
system. 

Simple  probability  factors  (e.g.  with  additive  combination)  and  the  certainty 
factors  provided  by  THAICS  provided  an  easily  handeled  method  but  sometimes  it 
lacked  flexibility.  In  many  cases,  a  linear  scale  of  plausibility  does  not 
adequately  describe  all  the  knowledge  on  the  chances  whether  the  fact  is  true 
or  false.  Moreover,  different  kinds  of  rules  need  a  different  way  to  combine 
the  certainties  of  their  premises  and  the  rule  to  get  the  conclusion's  cer¬ 
tainty  factor.  The  same  problem  arises  when  facts  are  derived  from  several 
rules  and  the  cobmined  certainty  factor  should  depend  on  some  degree  of  inde¬ 
pendency  of  the  rules.  Finally,  the  certainty  factors  do  not  allow  non-mono- 
tonic  reasoning.  If  an  intermediate  fact  in  some  chain  of  conclusions  has  a 
plausibility  of,  say  .5,  no  evidence  can  raise  the  plausibility  to  more  than 
.5  while  on  the  other  side,  no  indr»'  indent  counter  argument  can  get  the  plau¬ 
sibility  below  this  value. 

Bayesian  representation  of  the  dynamic  knowledge  (consultation  inputs  as  op¬ 
posed  to  the  static  knowledge  in  the  knowledge  base)  seems  to  be  concise  and 
flexible  enough.  The  Bayesian  approach  would  give  a  probability  to  any  type. 
The  problem  is  to  determine  adequate  a-priori  probabilities,  to  gather  and 
represent  the  answering  probabilities  which  may  depend  on  the  aspect,  and  to 
do  the  necessary  calculations  of  the  a-posteriori  probabilities.  Sequential 
Bayes  decisions  (in  the  form  of  a  Markovian  Decision  Process)  with  the  objec¬ 
tive  of  minimizing  costs  occured  by  misclassification  and  identification 
effort  was  considered  an  alternative  for  the  system  implementation.  This 
approach  would  take  the  a-priori  probability  and  would  determine  the  optimal 
question  by  evaluating  the  expected  cost  from  the  a-posteriori  probabilities 
arising  from  the  possible  answers.  Altough  the  calculation  effort  is  too  high, 
Bayesian  optimization  provided  a  very  good  model  for  the  explanation  of  the 
experts  behaviour  (e.g.  the  methods  switching  discussed  above). 

Puzzyness  turned  out  to  be  a  flexible  approach  and  was  rather  usefull  in  the 
first  stages  of  identification.  Fuzzy  sets  were  used  as  a  representation  of 
the  set  of  possible  aircrafts  after  the  first  identification  phase.  The  con¬ 
nection  between  user's  and  expert's  notation  was  based  on  the  idea  of  linguis¬ 
tic  variables. 

Using  a  2-difflen8ional  space  of  evidence  for  any  possible  aircraft  type  in 
order  to  combine  the  evidence  for  and  against  that  type  may  be  seen  as  a  rough 
view  to  bayes  estimate,  as  a  special  kind  of  fuzzy  set,  or  ao  the  simultaneous 
Shafer-Dempster  belief  function  for  "yes”  and  "no”.  Whether  the  evidences 
should  be  ccxnbined  like  probabilities  or  belief  (i.e.  mainly  multiplicative) 
or  like  (fuzzy)  logik  (using  minimum/maximum)  de^nds  on  the  kind  of  rule 
applied.  We  considered  it  the  most  adequate  method  under  the  given  time  and 
space  constraints,  but  to  process  it  some  kind  of  non-monotonic  reasoning  is 
neccessary  and  this  was  not  provided  by  the  shells  used. 


4.2.5.  System  Implementation  Approaches 

The  basic  approaches  for  a  rulebased  system  were: 

-  one  large  rule  per  a/c 

-  one  large  rule  per  object-attribute-value 

-  a  set  of  processing  rules  (metarules)  plus  a  database  containing  the  facts 

To  use  one  rule  per  a/c  reflected  the  "IF  that  AND  that  AMD  ...THEM  it's  this 
type"  explanations.  There  are  two  principal  approaches:  either  to  use  only 
such  attributes  that  will  discriminate  the  aircrafts  very  effective  or  to  use 
a  lot  of  attributes  that  are  the  same  for  any  aircraft.  While  the  second  ap- 
praoch  produces  lengthy  rules  but  runs  faster,  the  first  one  makes  the  consul¬ 
tation  more  lengthy  asking  a  lot  of  questions  on  very  special  attributes.  If 
there  is  no  possibility  to  weigh  the  attributes  and  to  use  and/or  combinations 
in  the  premises,  about  10  to  20  rules  may  be  neccessary  per  aircraft  type.  A 


25-14 


auperruXe  used  for  this  approach  reflected  sc^ethlng  lilce  a  fraae  or  form  that 
contained  all  possible  entries  (objects  and  attributes).  It  was  very  helpful 
in  the  development  process  %rhere  writing  a  rule  was  reduced  to  cutting  down  a 
superrule  to  the  needed  attributes  and  filling  in  the  correct  values. 

To  use  one  rule  per  ob ject-attribute*value  gives  scmm  fussy^set  or  Bayes^like 
approach,  ^e  knowledge  on  one  aircraft  is  widely  spread  and  the  course  of  the 
consultation  is  hard  to  control.  If  no  precaution  is  taken,  this  leads  very 
quickly  to  senseless  questions  and  to  overloaded  menues.  The  superrule  used 
for  this  approach  reflected  something  like  a  list  of  all  possible  aircraft 
types. 

To  use  a  database  or  list  representation  of  all  the  facts  combined  with  meta¬ 
rules  for  the  consultation  control  and  information  weighting  seems  to  provide 
a  good  solution,  but  it's  rather  difficult  to  implement.  The  database  struc¬ 
ture  needs  to  be  very  flexible.  To  control  the  questions  in  a  rather  general 
manner  semns  not  possible  since  the  structure  of  the  )cnowledge  is  flexible  and 
depends  on  the  dynamic  knowledge  itself.  This  approach  may  end  in  an  intelli¬ 
gent  search  through  a  tree-like  structure  and  may  represent  an  "expert  reco¬ 
gnition  handbook  user"  instead  of  an  identification  expert  for  aircrafts, 
nevertheless,  this  approach  may  be  used  to  implement  an  already  developed 
system.  It  also  isay  be  used  to  produce  a  widely  useable  identification  shell 
which  will  be  easily  transferred  e.g.  to  mushroom  identification  but  will  con¬ 
tain  no  facts  or  problem  solving  knowledge  of  the  special  area. 


4.3.  Implementations 

The  system  to  be  implemented  should  be  dialog-oriented,  and  must  comprise  con¬ 
cepts  of  uncertainty.  The  numbers  of  types  a  system  could  handle  will  be  easi¬ 
ly  increased  by  a  factor  of  2  to  10.  It  is  given  only  to  have  a  scale  for  the 
numbers  of  rules  and  rule-classes  in  the  system. 

4.3.1.  A  Plat  Rulebased  System 

This  system  was  intended  as  a  first  prototype  to  test  the  feasibility  and 
acceptance  of  DAVID  on  a  low  cost  level  (less  than  one  week  implementation 
effort).  It  was  build  up  using  a  typical  PC-shell  (PICO)  which  did  not  allow 
to  structure  object,  handle  incertainties  or  use  metarules.  Hence,  lot  of  the 
knowledge  structuring  done  before  could  not  be  carried  over.  The  XS  was  imple¬ 
mented  as  a  flat  system  (any  rule  was  directly  connecting  input  data  with  the 
result)  using  rules  that  contained  all  relevant  attributes  with  the  possible 
values  for  one  aircraft. 

At  the  first  approach,  %re  used  3  rules  per  aircraft  representing  the  front, 
top  and  side  view  used  by  aircraft  recognition  handbooks.  In  the  stage  where 
we  stopped  working  on  it,  the  system  could  handle  22  A/C  using  99  rules.  About 
4  rules  per  A/C  were  used,  covering  combined  top,  bottom,  front,  back,  and 
side  aspects  and  special  visibility  conditions.  The  set  of  attributes  asked  in 
the  rules  was  a  compromise  between  the  need  to  have  a  lot  of  information  to 
achieve  a  sure  identification  and  the  problem  that  a  single  hidden  object  or 
an  inaccurately  described  attribute  would  let  the  rule  fail.  Rules  with  a 
smaller  set  of  attributes  were  given  a  lower  certainty  udiich  implied  that  they 
were  not  invoked  when  there  was  a  better  rule. 

Any  rule  had  to  be  seen  in  the  context  of  all  the  other  rules.  Hence,  adding  a 
new  aircraft  to  the  rulebase,  adding  a  rule  for  an  existing  aircraft,  or  chan¬ 
ging  a  rule  yet  contained  in  the  knowledge  base  might  result  in  rewriting  a 
lot  of  rules.  Much  care  had  to  be  taken  to  those  rules  that  tried  to  identify 
aircrafts  with  a  small  amount  of  items  or  from  an  uncharacteristic  point  of 
view. 

To  give  an  example,  the  system  contained  5  rules  for  the  F-4  Phantom,  each 
used  up  to  10  attributes.  All  the  rules  used  general  features  such  as  the 
engine  position  in  the  fuselage  and  the  side  position  of  the  two  air  intakes. 
This  was  a  general  design  principle  in  the  development  of  the  rule  ^se  which 
helped  to  avoid  a  large  amount  of  very  special  questions.  Two  rules  were  main¬ 
ly  dedicated  for  the  front  view,  mainly  on  air  intake  and  the  position  and 
form  of  the  wings.  Two  rules  were  mainly  dedicated  for  the  top  or  bottom  view, 
mainly  on  air  intake  and  the  wing  shape.  These  rules  were  duplicated  in  order 
to  allow  different  answers  for  the  air  intake  form  since  PICO  did  not  allow  to 
formulate  an  OR  in  a  rule  and  the  air  intake  form  was  not  unique  (rounded  rec¬ 
tangle  or  oval,  the  later  answer  had  a  lower  certal..ty  factor).  One  rule  was 
mainly  dedicated  for  the  side  view  and  included  the  jet  position.  For 
aircrafts  with  a  rather  similar  counterpart,  more  and  larger  rules  were 
needed.  So  for  example  5  rules  with  up  to  15  attributes  were  used  for  the 
MI623/KI627  Flogger  to  separate  from  the  rather  similar  F-111  and  MRCA 
Tornado . 

The  prototype  was  presented  to  our  expert  partner.  The  system  provided  a  faci¬ 
lity  to  store  consultation  data  which  built  up  a  case  library  for  intensive 
testing  of  the  XS.  Several  experts  and  a  lot  of  Interested  people  used  the 
system  «diich  led  to  an  ongoing  is^rovement  of  the  rule  base. It  soon  became 
apparent  that  a  primitive  shell  would  not  suffice  for  our  needs.  In  order  to 
accoo^lish  a  fully  satisfactory  result,  up  to  10  or  20  rules  per  aircraft 


Aight  b«  HACMsary.  Mwarthalaaa,  working  with  the  prototype  hae  brought  a  lot 
of  insight,  fact  and  structural  knowledge  and  has  opened  our  eyes  for  the 
probleaa  connected  with  the  Identification  process. 
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4.3.2.  Staged  Identification 

With  Nixdorf's  XS-shell  TUXICB,  version  2.5,  a  systeei  was  iapleaented  that 
represented  the  experts  knowledge  aiui  problen  solving  procedures  In  a  auch 
better  way.  The  system  was  characterised  by  a  staged  identification  approach, 
the  explicit  transition  between  user  notation  and  true  %rorld  (or  experts) 
facts,  and  by  the  handling  of  uncertainty. 

With  its  present  knowledge,  the  system  can  Identify  22  A/C.  This  number  is  not 
detennlned  by  system  constraints  but  only  by  the  state  knowledge  base.  These 
aircraft  are  all  fighter  a/c  and  neither  delta-winged  nor  prop  driven  a/c  are 
contained,  so  an  enlargement  of  the  knowledge  base  to  other  types  would  not 
significantly  enhance  the  Identification  problems. 

Rules  represent  the  facts  about  the  aircraft  types,  the  problem  solving  knowl¬ 
edge  is  implicitly  contained  in  the  sequence  of  the  rules,  of  the  attributes 
in  the  rules,  and  in  the  stages  of  identification. 

The  1st  stage  builds  up  a  fussy  set  of  possible  aircraft  types  as  an  inter¬ 
section  of  the  fussy  sets  build  up  from  ccnmaon  attributes.  At  the  moment,  7 
fixed  attributes  are  used.  Since  the  questions  are  context  sensitive  (e.g.  if 
the  air-intake  is  not  visible,  the  fora  of  air-intake  is  not  asked),  between  5 
and  7  questions  will  be  asked. 

On  the  2nd  stage  the  investigation  concentrates  on  those  aircraft  that  re¬ 
mained  in  the  fussy  set  of  possible  ones.  These  are  tried  to  exclude  by  means 
of  cosason  attributes.  For  any  aircraft,  4  to  G  attributes  are  used  in  context 
sensitive  questions.  The  attributes  used  for  this  stage  have  been  chosen  to  be 
mostly  the  same  in  order  to  provide  a  short  overall  response  time. 

The  system  contained  in  this  stage  90  rules,  among  these  %fere 

22  rules  for  combining  the  notations  of  the  user  and  the  expert,  for  fussy 
terms,  and  for  the  handling  of  unknown  or  hidden  attributes  (e.g.  "if  air-in¬ 
take  is  invisible  then  form  of  air-intake  is  unJcnown*), 

36  rules  for  the  first  stage  fussy  set  determination  (one  rule  for  any  value 
of  any  attribute,  any  rule  has  as  much  conclusions  as  there  are  possible  A/C 
for  this  value  of  the  attribute)  including  one  rule  for  the  fussy  set  inter¬ 
section  , 

22  rules  for  the  2nd  stage  exclusion  by  means  of  comnon  attributes  (One  rule 
for  any  A/C,  any  rule  hae  as  much  propositions  as  there  are  attributes  to  be 
looked  at ) , 

2  rules  for  output  control  (printing  rules), 

8  rules  for  general  control  such  as  automatic  instantiation  of  objects 

The  taxonomy  contained  7  objects  and  in  total  43  attributes  with  about  250 
values  among  which  the  imaediate  a/c  properties  and  the  user  inputs  each  used 
about  10  attributes  and  50  values  (cf  figure  7.).  The  aircraft  types  in  the 
two  different  identification  stages  and  in  the  6  preselection  fussy  sets 
formally  added  23  types  each  time. 

Two  further  stages  (called  3rd  and  4th  stage)  are  just  in  implementation  and 
will  each  involve  about  30  special  attributes  for  a  more  concise  (3rd)  or  a 
definite  Identification  (4th  stage),  each  using  one  rule  per  aircraft.  Three 
rules  controll  the  Identification  procedure.  Depending  on  the  number  of  air¬ 
craft  left  after  the  first  and  second  identification  stage,  the  system  contin¬ 
ues  either  with  the  routine  questions  or  asks  for  the  special  attributes  con¬ 
nected  with  the  remaining  aircrafts.  This  parallels  the  expert  who  aks  more 
specific  questions  if  there  are  less  possible  types  and  anks  sooie  test  ques¬ 
tions  if  only  one  possible  type  is  left. 


4.3.3.  Integrated  Approach 

An  Impleaientatlon  that  Is  closer  to  the  expert's  notations  is  planned.  It  will 
be  implmsented  using  the  new  version  3.0.  of  TWAICB  which  provides  some  fea¬ 
tures  of  object  oriented  programming.  Alternative,  a  workstation  based  shell 
such  as  NBXPBRT  or  BPITOOL  or  a  hybrid  tool  such  as  LOOPd  or  KBB  may  be  used. 
The  system  will  combine  facts,  objects,  and  problem  solving  methods. 

In  this  systmn,  the  rules  represent  the  knowledge  about  problem  solving.  Facts 
about  A/C  are  contained  in  the  hierarchical  object  structure  and  in  the 
object's  attributes.  The  object  hierarchy  is  such  as  In  the  semantic  net.  The 
values  of  the  attributes  used  in  the  identification  process  will  be  kept  in  a 
database.  This  allows  to  do  stinor  changes  or  addition  of  a  type  tdiich  fits 
into  the  present  sceme  without  changing  the  expert  systems  rule  base.  The  rule 
base  or  taxonomy  of  the  system  has  only  to  be  changed  If  a  new  expert  behav¬ 
iour  is  detected  or  a  new  aircraft  is  added  which  is  structurally  different 
fron  that  known  before.  The  data  base  must  be  flexible  enough  to  allow  struc¬ 
tural  modifications  without  necessitating  a  reload  of  the  data. 


Tha  procasslng  of  tha  rulaa  can  ba  controllad  by  aatarulaa  and  supaxalaad  by  a 
rule  browaer.  This  provides  the  flexibility  to  change  the  problaa  solving 
strategy  froa  general  to  special  questions  and  vice  versa  depending  on  the 
infomation  available  at  the  sKMsent. 

The  new  systesi  will  have  a  graphical  Interface  consisting  of  a  cosiblnatlon  of 
ceumed  pictures  and  elesMntary  graphics.  This  will  allow  to  produce  menues 
e.g.  for  the  possible  shapes  of  a  wing  or  to  give  the  user  a  tool  for  the 
Input  of  span,  angle  of  sweep,  and  locations  relative  to  the  fuselage  by  using 
saall  pictures  and  a  display  oriented  device  such  as  a  siouse. 


4.4.  Lessons  Learned  from  DAVID 
4.4.1.  Lessons  on  Expert  Systems 

Expert  systems  provide  a  potrarful  tool  to  solve  decision  problems  for  iriilch  no 
algorithmic  solution  exists.  By  rapid  prototyping  (modelling)  and  working  with 
the  knowledge,  a  much  deeper  Insight  is  gained.  Even  whan  time  or  space  con¬ 
straints  or  the  need  to  do  a  lot  of  conventional  dataprocesslng  (number 
crunching,  signal  processing,  nusnrlcal  algorithms)  force  to  use  a  high  order 
language  or  even  aaaoibly  language,  the  expert  system  may  serve  as  a  basis  for 
a  conventional  program. 

Expert  systems  are  easier  to  assess  than  conventional  decision  methods.  While 
it  takes  a  lot  of  experience  to  see  which  parameter  la  responsible  for  some 
special  behaviour  In  a  Kalman  filter,  polynomial  classifier,  or  linear  pro- 
gramm  and  what  must  be  changed  In  case  of  malfunctions,  in  a  knowledge  based 
system  the  connection  between  the  behaviour  and  tha  rules  and  facts  Is  rather 
clear.  Even  If  the  behaviour  of  the  system  cannot  ba  easily  seen  from  the 
knowledge  base,  unexpected  reactions  can  siostly  be  traced  down  to  some  pices 
of  knowledge. 

This  also  faces  the  knowledge  engineer  with  the  problem  that  the  user  wants  to 
see  or  even  write  the  rules.  This  In  critical  In  those  cases  idtere  a  lot  of 
structuring  had  to  be  done  In  order  to  implement  the  system.  It  brings  also 
Che  danger  that  the  expert  begins  to  think  In  rules  or  changes  his  behaviour. 

The  applicability  of  today's  shells  Is  bounded  by  their  slow  reaction  time  and 
knowledge  representation  mechanisms  that  are  sometimes  not  powerful  and  flexi¬ 
ble  enough.  Of  course  there  Is  a  tradeoff  between  the  power  of  a  tool  and  the 
teaching  necessary  to  use  It,  but  at  the  moment,  all  tools  are  far  from  tha 
optimum.  Also  some  additional  features  are  neccessary.  so,  e.g.  non-monotonlc 
reasoning  Is  necessary  ( "if  air-intake  is  not  visible  then  a/c  is  P-111 
rather  than  NRCA  Tornado")  and  a  shell  or  tool  should  provide  an  easy  approach 
to  outside  data  and  prograu  and  a  flexible  way  to  combine  uncertainties. 


4.4.2.  Lessons  for  an  Identification  System 

We  think  that  the  staged  Identification  combining  standard  and  requested  data 
provides  a  good  approach  to  Identification  tasks  whose  structure  may  be  car¬ 
ried  over  to  radar  NCI.  In  this  application,  the  standard  data  (as  used  for 
the  first  fussy  set  and  the  following  step)  may  be  all  routine  data  from  the 
sensors  such  as  radar  cross  section  and  echo  modulations  from  tha  radar  and 
the  ESN  classification  of  the  target's  nose  radar  that  are  handed  to  the  ex¬ 
pert  system  In  every  Identification  cycle.  If  neccessary,  the  radar  may  re¬ 
quest  more  data  (e.g.  track  history),  further  measurement  (e.g.  at  another 
frequency)  or  further  evaluation  of  the  measured  data  (e.g.  peaks  of  soma 
autocorrelation  spectrum  or  the  jitter  of  the  nose  radar's  pulse  repetition 
Intervalls).  We  think  that  DAVID  may  be  transformed  to  serve  as  a  basis  for  an 
Ada  program  for  non  cooperative  Identification. 


5.  Conclusion 

For  tasks  of  the  complexity  needed  to  provide  usefull  (not  toy)  avionics 
expert  systems,  a  shell  or  toolbox  doesn't  exists  and  will  -  In  the  authors 
opinion  -  haixlly  will  exist  in  the  next  few  years.  It  may  be  worthwlle  to 
build  up  a  dedicated  shell,  say  for  display  handling,  multi  sensor  fusion, 
mode  selection,  or  gracefull  degradation  tasks  In  order  to  use  It  In  several 
applications  but  It  Is  unlikely  that  a  commercial  shell  or  a  stripped  avionics 
ZS  will  satisfy  for  such  a  task.  It  may  be  a  failure  to  think  that  good  XS 
will  ever  bo  created  by  an  "Intelligent  tool"  transferring  the  experts  un¬ 
structured  peaces  of  Information  Into  a  bag  of  rules. 

A  good  software  engineer  plus  an  excellent  support  environment  and  concise 
Ideas  and  concepts  will  perform  better  than  an  inexperienced  user  supported  by 
a  highly  sophisticated  ZS-tool. 

Expert  systems  are  not  the  only  way  to  achieve  these  goals,  tha  X8  technology 
should  t>e  combined  with  other  AI  techniques  such  as  pattern  and  Image  recogni¬ 
tion  or  automatic  learning,  with  conventional  dec.lslon  techniques  such  as 
mathematical  programming,  game  and  risk  theory  and  with  software  engineering 
principles . 
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Keverthelet.  XS  nethods  are  needed  to  solve  tasJcB  where  expert  knowledge,  heu¬ 
ristics,  concepts,  and  knowledge  representation  and  processing  are  important 
to  solve  a  problem  and  for  this  approach  XS-tools  are  needed  to  support  the 
software-  and  knowledge-engineer  in  his  work  of  knowledge-acquisition,  model¬ 
ling,  structuring  and  rapid-prototyping.  The  asKtunt  of  work  necessary  to  come 
to  a  perfect  systois  %»ould  be  much  greater  without  the  support  of  good  tools 
and  paradigms.  For  airborne  applications  in  the  near  future,  ZS  may  primarily 
be  used  as  a  tool  to  develop  prototypes,  gaining  deeper  insight  into  the  prob¬ 
lem,  and  producing  a  well  established  developiBent  baseline  that  will  either  be 
impicaented  in  conventional  software  or  may  be  running  in  some  stripped  form 
in  a  real-time  environment. 


6.  Literature 

McTigue,T.V.  (1982)  F/A-IS  Software  development  -  A  Case  Study.  Ins  AGARD  AVP 
Preprint  Mo.  330  Softvrare  for  Avionics  pp  39-1  -  39-15. 

Buchanan, B. G. ,  Shortliffo,B.H. (1984) »  Rulebased  Expert  Systems.  Addison- 

Wesley,  Reading,  Haas. 

Conner,  M.S.i  Low-cost,  rugged  commercial  computers  fit  military  needs,  EDM, 
December  24,  1987. 

Harmon, P.,  King, 0. (1986 ) t  Expertensysteme  in  der  Praxis.  Oldenbourg,  Mtinchen. 
(origt  Expert  Systems  -  Artificial  Intelligence  in  Business,  1982,  Wiley) 

Hayes -Roth, F. ,  Waterman, D. A. ,  Lenat,D.  (1983) t  Building  Expert  Systems. 

Addison-Wesley,  Reading,  Hass. 

Jackson. R. ( 1986) 1  Flying  Modem  Jetfighters.  Patrick  Stephens,  Wellingborough. 

Newell, A.  (1969)  Heuristic  Programming. In:  Aronofski  (ed.)  Progress  in 
Operations  Research  , Wiley,  N.T.,  pp  363  -  413. 

Wood,  D.  (1982)  Jane's  World  Aircraft  Recognition  Handbook.  Jane's  Publishing 
Company  ,  London . 


25-18 


DISCUSSION 


G.fliiiM,UK 

An  identification  system  can  either  operate  on  a  single  set  of  information  which  is  “frozen"  or  on  successive  sets  which 
are  refreshed.  In  the  latter  case,  these  sets  nuy  coirespond  to  more  detailed  images  as  the  target  range  is  reduced.  To 
which  of  these  does  the  systmn  described  by  the  author  correspond? 

Author's  Reply 

The  set  of  information  in  the  course  of  one  consultatioa  is  not  fixed,  but  determined  actively  by  DAVID  in  the  course  of 
the  consultation.  The  information  gathering  is  controlled  by  the  procedural  knowledge.  Although  DAVID  was  intended 
for  the  description  of  one  picture  and  cannot  handle  temporal  knowledge,  the  insertion  of  new  knowledge  from  more 
accurate  pictures  is  possible  via  the  “change  answers"  feamre  of  the  shell  TWAICE.  For  example,  you  may  change  the 
attribute  “position"  of  the  object  “air  inlet"  from  “unknown”  to  “not  in  the  nose”  and  from  this  to  “^ow  the  ailerons 
first  third".  Each  new  answer  would  lead  to  a  rework  of  the  rules  by  the  inference  engine,  leading  to  a  more  accurate 
identification. 


J.G.BrevoC,  Fr 

1 .  Could  you  provide  more  details  on  the  expertise  collection  in  your  DAVID  expert  system:  how  many  experts? 
how  much  time  did  it  take?  how  did  you  proceeed? 

2.  What  applications  do  you  foresee  for  expert  systems  in  the  near  funire?  What  delays  are  necessary  before 
beginning  to  have  real-time  expert  systems  (XS)? 

Author’s  Reply 

1 .  The  expert’s  knowledge  was  important  mainly  for  problem  solving,  e.g.,  how  to  proceed  and  what  properties  are 
important.  Literature  exists  for  the  “focts"  data  base  as  well  as  for  the  recognition  process,  e.g.,  in  the  German 
Army  AIL  recognition  Handbooks.  Our  main  expert  was  formerly  with  the  Air  Force,  in  the  first  stages,  we  made 
case  studies  and  eventually  we  were  able  to  assess  the  systems  behaviour  and  therefore  didn't  have  to  discuss  all 
types  with  the  expert.  The  development  time  was  one  year. 

2.  I  have  sketched  some  application  areas  in  the  papers.  Other  avionic  groups  with  an  increasing  difficulty  are: 

—  Groundbased  —  development  tools 

—  support  systems 

—  Airborne  —  decision  support 

—  display  and  moding 

—  sensor  application 

—  mission  oriented  tasks 

XS  for  real  time  applications  will  arise  in  several  steps,  each  of  them  bringing  the  XS-paradigm  (heuristic 
experience-based,  knowledge  processing  systems)  and  XS-approaches  (value  based  and  object-oriented 
prograrttming,  browsers,  implementation  by  specification,  etc.)  to  avionics  application: 

—  XS  as  a  method  for  gathering  in  sight  and  experiences 
—  XS  as  a  specification  for  standard  language  implementations 

—  compilers  for  XS  to  HOL 

~  real  time  XS  with  no  learning  or  explanation  facilities 

—  real  time  XS  with  the  full  power  of  Artificial  biteiligence  (AI).  Expert  systems  are  now  mature  enough  for  the 
first  two  steps,  the  third  one  is  in  work,  as  seen  in  the  conference.  Maybe  at  the  next  conference  we  will  be  one 
step  ahead. 
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ABSTRACT 

A  brief  reainder  on  Artificial  Intelligence  and  Expert  Sye^eBa  will  be  Bade  aa  an 
Introduction.  The  Intereat  and  dlfflcultlea  relating  to  this  new  technique  will  then  be 
expoaed.  An  exaBple  of  expert  ayatea  developaent  for  AS30L  weapon  ayatea  will  be  given 
to  llluatrate  the  polnta  already  atated,  through  thla  experience.  To  conolude,  the 
proapecta  of  thla  technique  for  avlonlca  will  be  drawn. 


1 .  IRRODOCTIOM 

The  Intereat  In  Artificial  Intelligence  (A. I.)  and  Expert  Syateaa  (E.S'a)  atarted 
In  the  80'a,  whan  It  could  be  eatlaatad  that  theae  new  technlquea  Bight  atep  froa 
reaearch  to  Industrial  application.  A. I.  Is  a  technique  consisting  In  trying  and 
reproducing  on  aaohlnesi  behaviours  which  should  be  considered  as  Intelligent,  if  they 
were  huaan.  E.S'a  are  a  branch  of  A.I.t  they  are  designed  to  perfora  the  saae  type  of 
valuation  aa  a  huaan  expert  In  a  Halted  field.  In  fact,  this  technique  basically  uses 
and  concerns  knowledge  thru  data  processing  aachinea. 

To  reproduce  on  a  coaputer  behaviors  which  can  be  conaldered  aa  Intelligent,  this 

Bust  acheaatlcally  be  provided  with  functions  corresponding  to  the  main  features  of 

intelligence  ) 

-  learning  capability. 

•  Heaorlaatlon  capability. 

-  Deduction  capability. 

Falling  any  one  of  theae  faculties,  neither  aan  nor  aaohine  can  be  considered  aa 

being  Intelligent,  and  not  even  healthy  as  regards  aan  ! 

Subjects  concerned  by  A. I.  basically  Include  > 

-  Expert  Syateaa. 

-  Robotics. 

-  Decisional  aid. 

-  Voice  and  signal  synthesis  and  recognition. 

-  Planning. 

-  Project  unageaent. 

-  Inforaation  retrieval. 


As  the  knowledge  and  experience  of  huaan  experts  fed  to  a  aachlne  aay  enable  non¬ 
experts  to  act  like  "nearly-experts" ,  avionics  diagnosis  Is  concerned  by  this  technique. 

Despite  the  proalslng  feature  of  this  technique,  a  nuaber  of  difficulties  are 
identified  : 

-  Technical  novelty  for  which  application  methods  are  not  yet  well  run. 

-  Validation  problea  for  the  knowledge  bases  thus  Involved  (coherence,  absence  of 
conflicts,  etc.). 

-  E.S's  conviviality  and,  oonsequently.  Intelligence  of  the  aan/aachine  Interface.  This 
point  relating  to  the  understanding  of  the  natural  language  is  still  to  be  solved  to 
provide  all  users  with  easily  operable  E.S's. 

Among  Its  A. I.  aotlvitles,  aerospatiale  has  developed  an  E.S.  designed  for  the 
aaintenanoe  of  a  alsslle  launcher.  The  basic  qualities  expected  from  an  E.S's  have  been 
checked  1 

-  Heaorlzatlon. 

-  Availability. 

-  Diagnosis  explanations. 

-  Flexibility. 

-  Portability. 

-  Conviviality. 

This  exaaple  allowed  understanding  the  general  Interest  of  A.  I.  for  Its 
contribution  to  avionics  aaintenanoe,  as  well  as  the  difficulties  It  aay  hold. 
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2.  KXPin  sisms  -  Gtmiu.  coasiDiuTioas 

Expert  Syeteas  are  a  sub-set  at  Artificial  Intelligence)  as  indicated  by  their 
naae,  they  perfora  expertise  in  a  Halted  doaaln,  an  expertise  coaparable  with  that  of  a 
huaan  expert  in  the  saae  doaaln.  Hereinafter  is  a  review  of  main  considerations  relating 
to  E.S's. 

2.1.  Basic  Conditions  to  develop  an  K.S. 

To  develop  an  E.S.>  the  following  basic  conditions  must  be  net: 

-  One  or  more  experts  in  the  donain  are  existing. 

-  The  expert (s)  are  aotlvated. 

-  The  expertise  doaaln  is  clearly  deterained. 

-Hunan  expertise  in  the  doaaln  is  neither  too  short  (1  hour,  for  instance),  nor  too 
long  (1  year,  for  Instance). 

2.2.  General  Deaorlptlon  of  E.S's 

An  E.S.  is  a  data  processing  system  whose  software  usually  includes  five 
modules  ) 

-  An  inference  engine. 

-  A  knowledge  base. 

-A  knowledge  acquisition  module. 

-  A  factual  base. 

-A  user's  dialogue  nodule. 

Inforsution  of  the  expertise  dosaln  are  entered  in  bulk  by  the  expert,  via  the 
knowledge  acquisition  module,  in  declarative  node  Instead  of  imperative  mode. 

Facts  noted  by  the  user  for  expertise  are  entered  in  the  factual  base  via  the 
user's  dialogue  module. 

The  Inference  engine  performs  deductions  relating  (inference)  the  knowledge  base 
elements  corresponding  to  the  facts.  Thru  successive  deductions,  the  inference  engine 
reaches  diagnosis.  The  record  of  knowledge  elements  involved  during  Inference,  provides 
diagnosis  explanation.  The  above  operating  process  is  quite  similar  to  the  human 
intelligence  one. 

The  new  and  interesting  feature  of  A. I.  actually  is  the  fact  that  the  sequential 
imperative  process  experienced  until  now  in  conventional  programs  is  broken.  Indeed, 
knowledges  are  not  necessarily  entered  in  a  pre-established  order  and  are  stacked  as 
received  in  the  knowledge  base  as  the  expert  transfers  the  knowledge  to  the  E.S.  This 
evidences  the  possibilities  offered  by  this  novation  and  the  resulting  flexibility.  It 
is  possible  to  enrich  the  system  with  new  knowledges  obtained  thru  reflection  or 
experience. 

2.3.  Basic  Components  of  E.S's 

He  shall  know  review  the  basic  components  of  the  E.S's  providing  representation 
of  the  knowledge,  modelization  of  the  reasoning  and  the  data  processing  frame-work. 

2.3.1.  Enowledge  Representation 

Knowledae  representation  modes 

Depending  on  the  subject  being  processed,  knowledge  representation  in  the 
knowledge  base  can  have  various  forms  : 

-  Production  rules. 

-  Semantic  networks. 

-Structured  objects  (schemes,  frames). 

-  Hybrids. 

It  should  be  noted  that  no  universal  knowledge  representation  mode  is  available, 
which  also  means  that  the  "universal*  E.S.  does  not  exist. 

The  representation  node  based  on  production  rules  is  well  adapted  to  diagnosis 
and  was  consequently  selected  for  diagnosis  E.S.  described  in  further  paragraph. 

Production  rules 

Production  rules  are  statements  having  the  following  form  i 

IF  <preBlse  1> 

AND  < premise  2> 

AMD . 

THEN  <  conclusion  1> 

AND  <oonolusion  2> 

AMO . 
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Here  la  a  production  rule  exaaple  : 

IF  <you  are  chilly> 

AND  <liable  to  ohlll3> 

AND  <the  aeteo  foreoaata  a  cold  spell  for  toaorrow> 

THEN  <you  should  wrap  yourself  up  toBorrou> 

This  exaaple  Is  deliberately  simple  and  easy  to  understand  by  a  non  expert,  so  as 
to  better  Illustrate  the  fora  than  the  substance  of  production  rules. 

Each  rule  foras  a  knowledge  atoa;  to  cover  the  domain  of  a  mean  complex 
expertise,  200  to  300  rules  sunoarlzlng  the  human  expert  knowledge  should  be  used. 

Prngraimine  Lanauases 

Knowledge  whose  representation  mode  was  explained  hereabove.  Is  expressed  In 
languages  specially  designed  for  A. I.  In  order  to  handle  concepts  (thus  knowledge) 
Instead  of  exclusively  digital  values.  The  better  known  are  LISP  (List  Programming)  and 
PROLOG  (from  French  i  PROgraasaation  LOGique).  These  are  the  A. I.  basic  languages. 

Furthermore,  these  languages  aiay  be  used  to  set  up  object  oriented  languages  for 
knowledge  representation  as  structured  objects  already  mentioned  hereabove. 

Nevertheless,  It  can  be  noted  that  a  number  of  programs  use  conventional 
languages,  such  as  PASCAL  and  C  which,  by  nature,  can  easily  be  applied  to  a  wide  range 
of  machines. 

2.3.2.  laferenoe  angina 

For  knowledge  representation  as  production  rules,  an  Inference  engine  Is  usually 
used.  It  performs  a  task  equivalent  to  human  reasoning.  In  fact,  this  Is  a  program 
which,  for  a  given  knowledge  representation  mode.  Is  fixed  and  independent  from  the 
expertise  domain.  When  finalized  it  needs  no  modifications,  whatever  the  knowledge  base 
evolutions. 

To  give  an  idea  of  the  reasoning  process  provided  by  the  Inference  engine,  let's 
consider  the  very  simple  case  of  a  knowledge  base  including  only  the  three  following 
rules  I 


R1  t 

IF 

<A>  THEN 

<B> 

R2  > 

IF 

<B>  THEN 

<C> 

R3  ! 

IF 

<J>  THEN 

<K> 

Rules  can  be 

used  In  two  different  waysp  either  in  forward-cheinlng  or  in 

backward-chaining.  He  shall  review  these  two  ways  hereafter  and  note  the  decoupling 
existing  between  inference  engine  and  knowledge  base,  which  forms  the  important 
technical  novation  of  the  A.I.  concept. 

Case  of  forward-chaining 

Assuming  that  fact  A  Is  ascertained,  the  Inference  engine  will  search  in  the 
knowledge  base  which  rule  contains  A  as  a  premise.  By  scanning,  it  finds  R1  which 
contains  B  as  a  conclusion.  B  then  becomes  a  deduced  fact  (from  basic  fact  A).  The 
Inference  engine  carries  on  searching  to  find  B  as  a  premise  for  a  rule  and  finds  rule 
R2  with  C  as  a  conclusion.  The  Inference  engine  carries  on  searching  and  finds  no  rule 
with  C  as  a  premise.  It  then  declares  C  as  a  conclusion.  The  answer  to  the  problem  set 
Is  that  A  produces  C.  The  Inference  engine  thus  has  performed  what  Is  equivalent  to  a 
deductive  reasoning. 

Case  of  backward-ohalnlns 

The  Inference  engine  operation  Is  Inverted  with  regard  to  forward-chaining.  It 
goes  backward  from  the  conclusion  (ascertained  fact)  to  the  premise  which  activates  the 
rules  chaining  to  the  conclusion.  This  premise  then  Is  the  cause  of  the  ascertained 
fact,  and  the  diagnosis  Is  obtained. 

Considering  the  same  knowledge  base  as  above,  assume  that  C  Is  ascertained,  the 
engine  searches  for  the  rule  containing  C  as  a  conclusion.  It  finds  R2  which 
hypothetically  becomes  candidate.  The  engine  then  proposes  premise  B  of  R2  to  the  user 
to  confirm  that  B  Is  an  ascertained  fact.  If  yes,  the  engine  carries  on  tracking  to  find 
a  rule  containing  A  (premise  of  HI),  fails  to  find  it  and  stops  tracking.  It  then 
delivers  Its  diagnosis  i  the  origin  of  the  ascertained  fact  C  Is  A.  The  engine  has  thus 
made  the  equivalent  of  a  hypothetlco-deductive  or  inductive  reasoning.  This  operating 
mode  Is  particularly  well  suited  to  diagnosis. 

2.3.3.  Data  ppooessing  frame-work 

Depending  on  their  importance  and  nature  of  their  expertise,  E.S's  may  be 
installed  in  various  types  of  machines,  starting  with  the  PC  compatible  micros,  then 
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■inlcoBputers  up  to  aulti-purpoae  coaputers  and  speoialized  aachinea  for  A. I.  This 
represents  an  extreaely  wide  price  range. 

It  should  be  noted  that,  at  present,  the  PC  coapatlble  alcros  represent  an 
enoraoua  field  of  lapleaentatlon  t  this  potential  aarket  can  explain  the  Increasing 
nuaber  of  Interesting  E.S's  aet  on  this  type  of  aachlnes. 

As  indicated  previously  the  use  of  LISP  and  PROLOG  languages  Is  specially  well 
adapted. 

It  shoulcf  also  be  noted  that  Increasingly  perforaant  shells  are  coaaerclallzed. 
These  shells  are  E.S's  with  no  knowledge  entered.  Depending  on  the  cases,  their 
utilization  Bay  noticeably  Halt  the  research  and  developaent  time  and  cost  for  the 
E.S's  to  be  created. 

2. A.  Technical  Interest 

The  technical  Interest  of  E.S's  basically  lies  in  the  following  qualities  : 

-  Explioability  i  an  E.S.  gives  the  reasoning  leading  to  diagnosis,  thus  contributing  to 
consultant  training. 

-  Beliabllity  t  an  E.S.  aakes  identical  reasonings  for  each  case;  for  a  given  problem, 
Its  deductions  are  thus  constant.  The  E.S.  has  an  advantage  over  the  human  expert  :  It 
experiences  neither  tiredness,  nor  stress,  nor  psychological  pressure  likely  to  affect 
its  diagnosis. 

-  Flexibility  :  updating  and  enriching  the  knowledge  entered  in  an  E.S.  is  very  easy. 
This  leads  to  development  cost  cutdown  with  regard  to  conventional  test  systems. 

-  Availability  ;  Utilizing  an  E.S.  allows  relieving  human  experts  from  repetitive  tasks, 
thus  leaving  them  free  for  sophisticated  expertises. 

-  Portability  t  As  an  E.S.  or  its  program  are  portable,  knowledge  can  be  better  shared, 

-  Memorization  :  Using  an  E.S.  permits  ensuring  knowledge  preservation  In  a  Company  or 
Administration.  The  E.S.  has  an  advantage  over  the  human  expert  t  no  risk  for  memory 
blanks,  even  temporary,  likely  to  affect  the  diagnosis  validity. 

The  above  list  of  qualities,  although  not  exhaustive,  can  be  summarized  In  one 
quality  i  INTELLIGENCE. 

Utilization  of  E.S's  concerns  Increasingly  numerous  and  wide  domains  t  INDUSTRY, 
FINANCE,  LAW,  ECONOMY,  ADMINISTRATION,  MEDICINE,  GEOLOGY,  CHEMISTRY,  ...  and  obviously, 
AVIONICS. 

2.5.  Difficulties 

Despite  the  obvious  advantages  of  A. I.  and  E.S's,  many  difficulties  of  various 
sorts  remain  t  psychological,  technical,  methodological.  He  shall  review  the  most 
Important. 

Expert  Motivations.  As  the  A. I.  basis  is  the  experts'  knowledge,  their  motivation 
Is  essential  for  achieving  an  E.S.  project.  Some  may  fear  to  see  their  domain 
threatened,  rejections  may  then  be  noted.  However,  even  expertise  Includes  repetitive 
and  non  valuatlng  tasks.  Creating  an  E.S.  can  then  be  considered  as  a  mean  to  relieve 
the  human  expert  from  these  tasks  so  that  he  can  Increase  his  knowledge  and  apprehend 
increasingly  sophisticated  expertises.  It  is  an  opportunity  for  hia  to  extend  his 
competences  and  Improve  his  background. 

Knowledge  Extraotion-Modelization.  Knowledge  extraction  is  a  technical  problem 
that  A. I.  specialists  Involved  In  a  project  must  solve  after  having  selected  :  the  know 
ledge  representation  mode,  the  reasoning  mode  and  the  data  processing  tools  corres¬ 
ponding  to  the  expertise  domain  concerned.  Thru  Interviews,  these  specialists  will  then 
have  to  extract  the  knowledge  from  the  (volunteering)  expert  then  to  modelize  It  and  to 
enter  It  into  the  data  processing  machine.  Although  not  being  a  major  difficulty,  these 
tasks  are  still  now  a  matter  of  specialists.  Just  a  minor  complication  sut  'ect  ;  to 
extract,  you  have  to  modelize,  and  to  modelize,  you  must  have  an  idea  of  the  knowledge, 
thus  you  have  to  extract  I  This  dilemna  is  usually  solved  ''by  developing  a  simplified 
prototype  of  the  E.S.  to  validate  solutions  and  then  step  to  real  size  system. 

(Mierenoe  of  the  Knowledge  Base.  For  an  E.S.  to  have  an  Intelligent  behavior.  Its 
knowledge  base  must  be  homogeneous,  without  redundancies,  contradictions  or  gaps. 
Furthermore,  during  the  system  life,  modifications,  amendments,  additions,  deletions  in 
the  knowledge  base  must  not  affect  this  hoaogensity.  For  bulky  knowledge  bases,  checking 
the  coherence  still  remains  a  heavy  unsolved  problea  as  far  as  we  know. 

E.S.  falidation.  E.S.  validation  Is  an  Important  problea,  both  methodological  and 
technical.  Indeed,  once  an  E.S.  has  been  created,  the  question  of  diagnosis  validity 
arises;  is  confidence  possible  without  testing  this  validity  7  How  to  test  It  7  Most 
often,  cross-expertises  are  perforaed  between  huaan  experts  and  E.S.  However,  this 
method  is  relatively  Inooaplete  as,  due  to  tiae  and  cost  reasons,  the  nuaber  of  cross- 
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expertises  Is  Halted.  In  soae  cases  for  which  expertise  has  a  vital  Importance, 

validation  aay  be  a  real  problem,  not  coapletely  solved  until  now. 

■atural  language.  In  order  to  give  the  E.S.  conviviality  In  their  interface  with 

the  users,  peralttlng  to  declare  them  Intelligent,  It  will  be  necessary  that 

understanding  of  natural  language  by  a  data  processing  aachlne  be  obtained.  This  Is  not 
yet  true  even  In  the  near  future. 

Salf-Laarnlng.  Although  research  works  are  conducted  in  various  laboratories, 

self-learning  of  an  E.S.  la  still  a  dreaa. 


3.  UMiaon  oa  as3o  lasbi  mipog  system 

3.1.  Oanaral 

Precision  guided  weapons  greatly  iaprove  efficiency  and  economy  of  Interdiction 
and  close  air  support  missions.  In  addition,  due  to  the  proliferation  of  accurate  short 
range  air  defence  system,  close  approach  attacks  pose  unacceptable  risks  for  tactical 
aircraft,  even  at  very  low  altitudes.  Thus  air  to-surface  weapons  must  providei 

-  pinpoint  accuracy) 

-  firing  distances  greater  than  the  range  of  close  defence  systems; 

-  aircraft  escape  manoeuvres  Just  after  launch. 

Asiong  all  guidance  modes,  laser  homing  is  one  of  the  most  attractive  answers  to 
the  above  conditions,  and  provides: 

-  outstanding  accuracy; 

-  low  coat,  laser  seekers  being  the  cheapest  available; 

-  versatility,  resulting  from  the  possibility  of  using  either  airborne  or  ground  baaed 
designation; 

-  firing  at  night,  and  even  under  limited  visibility  conditions. 

Furthermore,  laser  guidance  allows  high  performance  equipment  to  be  used  for 
detection  and  tracking  since  these  are  fitted  on  board  the  launching  aircraft  and  not  in 
an  expendable  weapon. 

3.2.  Air  Force  requlreaenta 

The  mission  of  Tactical  Air  forces  Include  close  support  and  Interdiction. 

Moat  close  support  targets  are  mobile,  armoured  or  unarmoured,  camouflaged. 

Most  interdiction  targets  are  fixed,  in  well  known  locations,  generally  hardened 
and  protected  by  air  defence  systems. 

Such  targets  (for  instance,  buildings,  shelters,  bridges,  dams,  air  defence 
radars,  depots,  etc.)  must  be  destroyed  by  weapons  which  have; 

-  very  effective  warheads; 

-  pinpoint  accuracy; 

-  a  firing  range  consistent  with  maximum  detection  range; 

-  the  possibility  for  launch  aircraft  to  manoeuvre  Just  after  launch. 

To  satisfy  these  requirements,  aerospatlale  has  developed  a  new  missile,  AS  30 
LASER,  with  laser  terminal  guidance. 

The  2k0  kg  warhead  comparable  with  the  remote  controlled  AS  30's,  provides  out¬ 
standing  effectiveness  against  hardened  targets  and  great  penetration  capability,  due  to 
Its  high  Impact  velocity. 

The  firing  range  (>  10  km)  Is  consistent  with  optical  detection  range  of  most  targets. 

Terminal  laser  guidance  was  selected  because  of  Its  pinpoint  accuracy,  and  thr 
possibility  for  the  launch  aircraft  to  manoeuvre  after  missile  launch. 

The  laser  designation  system  can  be  operated  either  by  the  launch-aircraft,  or  by 
another  aircraft,  or  by  a  ground  based  operator. 

For  pinpoint  interdiction  targets,  the  French  Air  Force  have  in  their  Inventory  a 
weapon  system  consisting  of  i 

-  the  JAGUAR  tactical  support  aircraft; 

-the  LASER  designation  pod  (Laser  Designation  Pod  t  L.P.D.),  developed  by  THOMSON-CSF 
for  acquisition,  automatic  target  tracking  and  designation  from  a  single  seater 
aircraft) 
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-  the  AS  30  LASER  ■ieslle,  developped  by  aerospatiela  (two  alesllea  to  be  carried  per 
sortie) . 

3.3.  naval  Air  Force  raqulreaenta 

Naval  targets  have  very  alallar 
characteristics  to  Interdiction  ground 
targets:  hardening,  surface  to  air 
defence  systeas,  good  definition. 

Their  excellent  contrast  with  the 
environment  makes  remote  detection 
easier. 

Against  such  targets,  the  AS  30 
LASER  la  perfectly  suitable  due  to  its 
accuracy,  range,  and  warhead,  mostly 
when  high  diaorlmination  and/or  visual 
identification  are  required  (crowded 
and  confined  areas,  such  as  harbours, 
channels,  fjords,  archipelagos). 


*.  A  SPECIFIC  APPLICATION  BT  AEROSPATIALE  t  EXPERT  STSTEM  FOR  AS  30  LASER  HISSILE 
LAONCHER 

A  missile  launcher  (ML)  is  a  unit  providing  the  Interface  between  the  carrier 
aircraft  and  the  missile.  It  allows  : 

-  attaching  the  missile  under  the  aircraft  and  transporting  it, 

-  starting  up  of  missile  units,  transmission  of  data  and  firing, 

-  missile  jettisoning  in  ease  of  emergency. 

It  consists  of  a  contoured  pod  including  about  twenty  electronic,  electro¬ 
mechanical  and  pyrotechnlcal  systems. 

The  ML  maintenance  consists.  In  case  of  failure.  In  locating  the  faulty  unit  and 
replacing  It  by  a  spare  unit.  For  this  purpose,  the  ML  is  tested  on  an  automatic  bench 

which  delivers  a  listing  Indicating  the  correct  or  Incorrect  test  results,  and  the 
location  of  the  faulty  unit.  Location  Is  often  affected  by  indetermination  between 
several  elements.  This  fault  location  function,  which  Is  most  Important  for  maintenance. 
Is  difficult  to  control  with  conventional  programming  and  cannot  really  evolve  (costs 
and  time)  to  Incorporate  experience  oontributions.  The  system  is  froxen. 

A  diagnosis  expert  system  was  set  up  to  Improve  this  fault  location.  The  test 
result  listing  constitutes  the  facts  entered  for  consultation.  In  non-real  time  as  no 
direct  connection  exists  between  the  test  bench  and  the  expert  system. 

Installed  on  an  IBM  PC  XT,  this  E.S.  uses  an  E.S.  generator  package  using 
knowledge  representation  based  on  production  rules. 

Programming  la  performed  In  a  language  very  close  to  natural  language  and  is 
based  on  80  rules  describing  : 

-  correct  operation  of  the  missile  launcher, 

-  cases  of  failure, 

-  servicing  errors. 

The  modifications,  additions  or  deletions  of  production  rules  are  very  easy,  as 
opposed  to  the  heavyness  of  program  evolutions  In  conventional  test  benches  which  are 
froaen  systems. 

tflth  regard  to  the  results  obtained  with  the  conventionally  programmed  test 
bench  : 

-  the  faulty  unit  rate  of  uncertainty  has  been  divided  by  3, 

-  the  number  of  ascertained  oases  has  been  multiplied  by  3, 

-  the  fault  location  programming  time  fora  much  better  result  has  been  divided  by  3. 

This  development  evidences  the  feasibility  and  Interest  of  E.S.  as  regards 
industrial  diagnosis.  The  results  obtained  and  the  qualities  mentioned  hereabove  permit 
envisaging  the  possibility  to  use  E.S.  for  Logistics.  This  Is  described  In  paragraph  A 
hereafter . 


5.  E.S.  PROSPECTS  FOR  ATIOHICS 

As  indicated  in  the  previous  paragraphs,  E.S.  can  be  assumed  to  be  an  Interesting 
contribution  to  Avionics,  both  from  the  operational  and  tool  aspect. 
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The  gains  which  can  be  expected  concern  mainly  : 

5.1.  Operation 

The  diagnosis  reliability  and  velocity  and  most  of  all,  the  indetermination 
decrease,  lead  to  increase  the  system  availability,  which  is  fundamental  for  the  user. 

5.2.  Reliability 

The  importance  of  handling  during  removal  and  refitting  operations  for 
maintenance  purposes  are  known  to  be  major  elements  as  regards  the  Mean  Time  Between 
Failures  (MTBF).  Thus,  having  a  reliable  diagnosis,  limiting  the  number  of  useless 
removal  and  refitting  operations  contributes  to  a  more  reliable  service  of  the  systems. 

5.3.  Cost 

As  a  consequence  of  the  two  previous  gains,  the  Life  Cycle  Cost  can  be  Improved 
thru  lower  rates  of  unavailability,  less  unjustified  returns  for  repair,  less  spare 
parts  stocks  due  to  an  improved  diagnosis  quality.  As  expertise  can  be  performed  by  non 
expert  personnel,  but  using  the  explanation  provided  by  the  E.S.,  their  level  should  be 
improved  and  a  gain  in  personnel  expenses  can  also  be  expected. 


6.  CONCLUSIONS 

Artificial  Intelligence  and  Expert  System  currently  benefit  by  a  fashion  effect 
in  the  media  which  very  often  mix  up  (foolish)  hopes  and  crual  reality.  We  tried  to  show 
that,  although  hopes  are  great  and  Justified,  more  is  still  to  be  achieved  in  these 
techniques  than  has  already  been  done. 

Nevertheless,  E.S.  are  no  longer  a  MYTH  but  a  REALITY.  E.S’s  can  contribute  to 
Avionics  by  improving  the  systems  operating  condition  upholding. 

The  most  important  problems  to  solve  or  difficulties  to  overcome  are  :  coherence 
of  the  knowledge  bases  and  validation  of  C.S’s. 

A  more  general  utilization  of  this  technique  and  improvement  of  its  performances 
depend  on  the  improvements  in  hardware,  software  and  peopleware. 

To  conclude,  the  most  important  thing  still  to  be  acquired  appears  to  be  the 
knowledge  of  the  knowledge. 


INTCOMTION  OU  MALOOUE  VOCAL  A  BORD  DIIM  AVION  DE  COMBAT 


Avions  Marcel  Daaaauit  -  Braguat  Aviation 
78  Qual  Marcel  DaasauH 
92  214  Saint  Cloud  -  FRANCE  - 


RESUME 

L'utillaatlon  d'avlona  d'armes  axtrhnement  manoauvranta,  dotAa  da  Syatimea  da  Navigation  at  d'Attaqua 
compiaxaa  parmattant  da  manor  8  bian  daa  miaalona  varlAet  dans  un  anvironnamant  hoitiio  (vol  an  zona 
annamla  8  tr8s  baaaa  altitude  at  par  tout  tempt)  place  la  pllote,  devenu  gettlonnalre  da  la  mittion,  dant  dot 
situationt  oil  la  charge  da  travail  at  la  ttren  sent  8  la  llmite  da  tat  potslbllH8a. 

Dant  ca  contexta,  I'amdnagamant  du  poata  da  pllotaga  ett  un  8l8ment  fbndamental  dant  la  niuttHa  da  la 
mittion  at  8  ce  titre,  ITntroductlon  da  dltpotHIft  da  dialogue  vocaux  utllltablet  Inddpendamment  da  I'activitb 
manualle  ou  vltualla  enrlchlt  contlddrablamant  rinterface  homma-machine  at  parmet  I'utllliatlon  dot  volet  oralei 
at  auditivaa  jutquTcl  pau  aolllcHAet  pour  la  dialogue  avac  la  machine.  Let  appllcatlont  potentiallet  dat 
dltpotiUft  vocaux  coneemant,  par  axemple,  r8nonc8  axplicite  dat  mattagat  d'alarmet  an  tynth8ee  vocale,  let 
commandet  reprenant  eartalnat  commandet  elatalquat  ditponiblet  an  eablna,  let  commandat  parmattant  par  un 
ordre  g8n8rtque  d'eflaetuar  tlmultandment  plutleurt  actlont,  etc. 

D'lmportanta  travaux  ont  8t8  man8t  an  Franca  tur  la  traltamant  da  la  parole  at,  dant  la  domaine 
adronautlqua,  I'appul  dot  Servicat  Offldelt  a  permit  d'atturer  la  trantHlon  antra  let  laboratolrat  at  I'lnduttrla. 
Cad  t'aat  concrdtltd,  d8t  1984,  par  I'axpArimentatlon  an  vol  tur  un  Mirage  d'un  boltler  da  raconnaittanca  vocale 
an  mott  Itoldt. 

Aulourd'hui,  una  nouvella  8tapa  ett  an  court  pour  I'axpArtmantatlon,  tur  I'avlon  RAFALE,  d'un  dltpotitn  da 
reconnaitaance  8  mott  enchatndt. 

L'oblal  da  cat  expotd  eat  da  prdterrtar  let  travaux  r8allt8t  aux  Aviona  Marcel  Dataault  -  Brdpuel  Aviation, 
an  coopdratlon  avac  CROUZET  at  avac  la  toutien  dot  Servicea  Offldelt,  la  SITE  at  la  DRET,  pour  atturar 
rimSgratlon  da  ca  nouveau  moyan  da  dialogue.  L'0$t0ntlel  da  i'expotd  aara  ralatif  8  I'utllitatlon  du  dialogue 
vocal  dant  una  cablne  concua  d8t  la  d8part  pour  accuelllir  un  tal  diapocitll.  Up  outll  d'attimatlon  da  la  charge  da 
travail,  deatind  8  I'analyta  dat  dlfWrantet  phatet  da  vol  avac  el  tant  commande  vocale  tara  prdaantd. 

1.  INTRODUCTION 

Lea  pilatet  d'avlon  da  combat  modemat  dvoluant  dant  un  anvironnamant  trdt  contralgnant  :  fadeurt  da 
chargaa  diavto  at  toutanut,  vol  8  trda  baaaa  altifuda  dant  un  millau  opdratlonnel  8  haute  dantltd  da  menacaa, 
vol  tout  tempt  da  lour  comma  da  null,  ....  C'ett  dant  ee  contexta,  qua  t'eltoctua  la  gattlon  du  Syttdme  da 
Navigation  at  d'Attaqua  (SNA)  dont  la  complaxltd  t'accroll  au  III  dat  anndea.  En  conadquanca,  la  pllota  aat 
confrontd  8  una  charge  da  travail  vltualla  at  manualle  qui  att  tana  prdeddent. 

Da  plut,  pour  rdduira  la  vuindrabilltd  da  I'avlon  an  combat  adrian,  una  manoauvrabllltd  trdt  Importante  att 
damandda,  condultant  alnal  8  una  prddomlnanca  dat  aviona  monoplace  dquipdt  da  tidgea  fortament  Inclindt. 
Cette  Incllnalton  t'accompagna  d'une  diminution  da  la  turface  utile  da  la  planche  da  bord,  llmitant  ainti  la 
rrambra  d'didmentt  ditponiblet  pour  la  prdaantatlon  dat  Inibrmatlona  at  pour  let  divertat  commandet.  II  atl  8 
remarquar  qua  lore  da  la  condulte  dat  phataa  critiquat,  I'attantlon  du  pllota  ett  concantrde  8  I'extdrlaur  da  la 
cablne  rddultant  alml  ta  capaeltd  8  gdrer  pteinemant  I'acquitltlon  dat  clblet,  I'utllitatlon  dat  contra.maturaa,  ate 
at  qua  la  pllotaga  t'affactua  avac  'let  Maint  tur  la  Mancha  at  la  Manette'  (concept  M3)  oii  da  nombreutet 
commandet  ont  did  ragroupdea. 

D'Importantt  effortt  ont  did  conaaerdt,  aux  Aviona  Marcel  Dattault-Bregurl  Aviation  (AMO-BA),  8  la 
conception  da  I'lntarface  pllota^tt8ma  afln  quo  la  charge  da  travail  reate  acceptable  pour  la  pllote  lore  da  la 
rdalltation  daa  miaalona  lea  plua  complaxet.  Alnal,  I'omplol  da  technologlea  dvoiudea  comma  la  viaualltatlon  tdte 
haute  grand  champ  8  optiqua  diffractive  at  la  vltaur-vltuel  da  catque,  amdilore  la  prdaantatlon  dat  Inlormatlona 
loraqua  la  direction  du  regard  aat  8  I'axtdrlaur  da  la  cablne.  Da  mdme,  la  vlaualltal  on  tdta  moyenne  eolllmatde, 
placde  tout  la  viaualltatlon  tdte  haute,  autorlaa  una  prita  d'Inlormatlon  plut  repMe  en  dvltant  I'accomodatlon 
vltualla  ndceaaalra  avac  lea  vlaualitatlont  claatiquaa  at  la  planche  da  bord  lore  daa  tranaltlona  da  la  petition  tdte 
haute  8  la  poaNlon  tile  baaaa.  Da  nouveaux  moyent  da  commande  ont  did  ndt  an  plaea  pour  diapotar,  8  partir 
d'una  aurfaea  rddulla,  daa  commandoa  ndcaaaalrat  pour  la  dialogue  avac  la  SNA.  II  t'agit  aaaantiallamant  da 
clavlart  muWplaxda. 

Juaqu'8  prdaant,  la  pllota  dltpoae  da  moyant  ndcaatllani  una  attention  vltualla  at  manualle  pour  dlaloguar 
avac  la  SNA.  L'lntroducUon  du  dialogua  vocal,  c'aat  8  dire  da  la  raconnaittanca  at  da  la  aynthdae  vocale, 
apporta  un  contort  arponomique  trdt  apprdciabla  pour  I'Introducllon  da  donndet  ou  da  commandet  at  pour 
I'annonce  da  mattagat  d'alarmet.  C'aat  un  moyan  da  commande  auppidmantaire,  toupla  d'emplol  el  aux 
multiplat  potalbUHdt,  utllltabla  Inddpandammam  da  I'acHvttd  manuella  at  vituelle,  no  demandant  aucun 
amdnagamant  an  plancha  da  bord. 


* 
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2.  INaOENCES  DU  DIALOGUE  VOCAL 


Si  le  dialogue  vocal  conatitue  un  apport  ergonomlque  Important  pour  I'lnterface  pilote-systeme.  11  est 
capandant  IndlapenaaMa  da  prandre  cartalnea  prioauUont  pour  son  Implantation  i  bord  d'un  avion  d'amias  an 
considdrant,  an  pramlar  lieu,  qua  c'eat  un  moyen  da  commande  Intdgrd  au  SNA.  Son  intdgration  i  bord  d'avions 
axiitants,  assentiallamant  pour  una  amdlioration  daa  commandas,  act  ralativement  delicate  at  le  conctat  general 
d'une  telle  tentative  laisaa  panaar  qua  la  commande  vocala  ne  paut  pas  etra  conslderde  comma  un  simple  addittt 
aux  autras  rnoyans  da  commande  axistant. 

En  aflat,  rndme  si  pour  I'Instant  le  dialogue  vocal  rapresanta  un  plus  ergonomlque  at  operationnal,  11  subsiste 
das  commandas  classiques  equivalantas,  an  tonctlon,  aux  commandas  enoncdes  e  la  voix.  L'incidence  da 
rintroduction  d'un  Boltier  da  Dialogue  Vocal  e  bord  d'un  avion  d'armes  conceme  la  nature  rndme  das 
commandas  classiques  alnsi  qua  I'lntegratlon  das  divers  elements  ou  equipamants  en  relation  avec  le  dialogue 
vocal. 

La  compatibilite  antra  las  commandas  classiques  at  la  commands  vocals  doit  etra  assures  par  un  choix  trbs 
precis  das  organas  manuals  da  commands  en  substituant  toutes  las  commandas  stablas  e  libalie  fixe 
(Intarruptaurs,  poussolrs,  rotacteurs,  claviers,  ...)  par  das  elements  Instables  ou  multiplexes.  II  ast  an  aflat  bien 
difficile  da  changer  retat  d'un  Interruptaur  stable  par  una  commande  a  la  voix  ! 

La  richesse  da  I'appllcation  vocala  se  caractertsa  par  le  nombra  da  fonctions  adrassables  par  le  dialogue 
vocal.  Pour  cala,  das  echangas  d'informatlons  sont  necassalras  antra  tous  las  equipamants  at  le  dialogue  vocal 
at,  par  consequent,  I'InterconnaxIon  da  tous  cas  elements  au  bus  avion  ast  Indispensable. 

L'integratlon  d'un  dlsposltlf  do  dialogue  vocal  sa  traduit  pour  la  cabins  par  une  compatibilite  das 
commandas  classiques  et  des  commandas  enoncees  e  la  voix  at  pour  'I'avlonique*  par  une  Interconnexion  au 
bus  avion  de  tous  las  equipamants  en  relation  avec  le  dialogue  vocal. 

3.  DEMONSTRATEUR  RAFALE 


Le  demonstrataur  RAFALE  est  un  avion  destine  i  tester  de  nouvsiles  technologies  qui  pretigurant  cellos  qui 
saront  utlliseas  sur  les  avions  de  combat  de  la  prochalne  decannia.  Des  sa  conception,  I'interlaca  pllota-systema 
a  ete  realisea  avec  le  souci  d'evaluar  de  nouveaux  concepts  en  matiera  de  visualisation  et  de  commandas. 
L'appllcatlon,  au  demonstrataur  RAFALE,  de  nouveliss  philosophies,  notamment  pour  le  dialogue  avec  le 
systems,  a  permis  la  realisation  d'une  cablne  mettant  an  oeuvre  des  solutions  originales.  Parmi  celles-ci,  figure 
le  dialogue  vocal.  Avant  de  devaloppar  le  type  d'appllcatlon  prevu  pour  raxperimantation  en  vol  d'un  dlsposltlf 
de  dialogue  vocal,  une  presentation  de  la  cablne  du  demonstrataur  RAFALE,  du  point  de  vue  de  I'lnterface 
pilota-systema,  donnera  une  illustration  des  rbgles  definles  au  chapitre  precedent. 


3.1  PRESENTATION  DE  LA  CABINE 

La  cabins  du  demonstrataur  RAFALE  est  concue  autour  d'un  slbge  ejectable  incline.  Cette  installation 
permet  I'execution  de  manoeuvres  soutenues  sous  fort  facteur  de  charge  tout  en  redulsant  notablement  leurs 
effets  physlologiques  sur  le  pilots.  L'utillsatlon  d'un  siege  fortement  incline  a  fait  I'obiat  d'etudes  approfondies  et 
son  Influence  sur  I'organisation  de  la  cablne  a  ete  trsitee  globalement  notamment  pour  I'ensemble  des  terminaux 
de  visualisation,  des  commandas,  de  la  tenue  du  manche  et  de  la  manette,  de  la  visibillte  exterteure . 

Le  dialogue  pllote-systeme  s'appule  essentlellement  sur  : 

•  trols  terminaux  de  visualisation, 

•  un  clavier  multiplexe, 

•  un  Paste  de  Modification  de  Parambtres  (PMP), 

•  das  commandos  situees  sur  le  manche  et  la  manette  des  gaz, 

3.1.1  TERMINAUX  DE  VKUALISAHON 

3.1.1.1  ViaUALWATION  TETE  HAUTE 

Las  informations  necassalras  au  pilotage  at  A  la  conduits  de  Is  mission  sont  presentees  dans  la  Visualisation 
Tete  Haute  (VTH)  i  optique  diffractive.  Celle-cl  permet  la  presentation  d’informatlons  pro|etees  i  I'infini  et  en 
superposition  avec  le  paysage  exterteur.  Les  caracterlstiques  photometriquss  et  la  valour  du  champ  visual  sont 
bien  supeiieurea  A  cellos  des  VTH  classiques. 

3.1.1.2  VnUAUSATION  TETE  MOVENNE 

Une  Visualisation  TAte  Moyenne  (VTM)  colllmatee  est  places  au-dessous  de  la  VTH  et  en  continulte  de 
champ  avec  celle-ci.  Ella  est  monochrome  multimode  (trace  cavalier  et  television).  Elle  presents  I'avantage 
important  d'etre  peu  sensible  A  I'edalrement  extArieur.  Elle  permet  la  presentation.  A  I'infini,  d'informatlons 
relatives  A  la  navigation  et  aux  systAmes  avion  alnsi  que  la  presentation  d'images  issues  de  capleurs  et  en 
particulier  d'une  camera  ventrale,  donnant  alnsi  I'impression  d'une  planche  de  bord  transparente.  Ce  concept 
permet  de  mlnlmlser  le  temps  de  prise  en  comple  des  Informations  lors  d'une  transition  de  la  position  tete  haute 
vers  la  position  tete  basse. 
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3.1.1  J  VraUAUSATION  TETE  LATfRALE 

Une  Visualisation  TMa  LatOrala  (VTL)  polyelwame  A  tuba  A  rayons  cattwUlquas  pemiM  la  prAsentotion 
d'informotlons  rslatlvas  A  la  situation  hortzontola  at  aux  systAmos  avion.  L'instaUaHon  do  la  VTL  sur  la  droita  da 
la  VTH  at  da  la  VTM  a  fait  rob|al  d'una  atlanUon  parttcutlAra  compla-tanu  das  contralntas  IMas  A  l'A)setlon.  En 
alM,  ITnstallation  du  pilots  sur  un  siAga  fortamant  fndlnA  a  pour  consAquaoca  da  'rsiovar*  las  gonoux  du  pflofs 
au  nivaou  du  tsimlnal  da  visualisation.  Do  plus,  las  contralntas  d'^actlon  Imposant  qu'uns  gords  suRlsanta  soit 
rsspsctAs  antra  la  gabarit  d'Ajaction  at  I'arAta  hortsontals  InMiisure  da  la  VTL. 

3.1.2  C0MMAN0E8 

3.12.1  CLAVIER  UULTIPLEXE 

Las  commandss  pour  I'lntroductlon  das  donnAss  ralativss  aux  radio-communications  at  A  la  navigation  ou 
pour  la  sAloctlon  do  modos  ont  AtA  rsgroupAes  sur  un  claviar  multi-fonctions,  llmitant  ainsi  la  nombre  da  postes 
da  commands  nAcsssaires.  Calul-cl.  situA  sous  la  visualisation  tAta  moysnna,  sst  lacllsmsnt  accssslUa  das  dsux 
mains.  II  est  composA  : 

•  d'un  ensambis  da  touchas  dAdlAss  ssrvant  ssssntisllsmant  A  I'lntroductlon  das  donnAas  numArIquas, 

•  d'un  afficheur  A  cristaux  llquidas  permsttant  la  visualisation  das  paramAtres  modlllAs. 

•  d'un  anssmbla  da  touchas.  chacuna  Atant  assoclAs  A  un  attichsur  A  cristaux  llquidas 

3.122  P08TE  OE  MODIFICATION  DE  PARAMETREE 

La  Posts  da  Modiflcatlon  da  ParamAtres  (PMP),  ImpiantA  sur  la  planchette  da  bord  gauche  permel  un  accAs 
rapids  pour  la  modiflcatlon  da  paramAtres.  Cat  AlAment  est  composA  d'una  couronne  extsma  permsttant  la 
sAlaction  du  paramAtra  numAriqua  A  modifier  at  d'un  bouton  tana  fin,  coaxial  A  la  couronne.  A  partir  da  la  valour 
courante  du  paramAtra,  la  modiflcatlon  ast  affsctuAe  A  I'alda  du  bouton  central  par  IrtcrAmentotion  ou 
dacrAmentation.  Un  bouton  poussoir  instabla  parmat  Agalamant  da  sAlectionner  ou  da  dAsAlecllonnar  la  calage 
altimAtrlqua  standard.  Une  fonction  annexe  da  chronomAtra  (iguia  Agalamant  avec  sa  commands.  Las 
paramAtres  modlflAs  son!  las  sulvanis  : 

•  las  canaux  das  postes  V/UHF  at  UHF. 

•  la  numAro  du  but  da  dostlnafion. 

•  la  calage  altimAtrlqua, 

•  la  valeur  du  saull  da  I'alarme  pAtrole  (Bingo), 

•  la  valeur  de  la  hauteur  de  garde. 

La  connexion  au  bus  numAriqua  est  assurAe  par  rintermAdialre  du  calculatsur  du  clavier  multi-fonctions. 
L'affichage  das  paramAtres  modlflAs  s'effectua  sur  la  visualisation  tAta  haute  at  dans  certains  eas,  Agalamant  en 
VTM  ou  VTL. 

3.122  COMM  ANDES  SUR  MANCHE  ET  MANETTE 

La  conception  du  manche  at  de  la  manette  das  gaz  a  fall  I'objel  d'una  Atude  ergonomique  poussAe  tant  au 
niveau  da  la  tenue  qua  de  la  disposition  de  toutas  las  commandes.  II  est  A  remarquer  qua  la  manette  das  gaz  est 
commune  aux  deux  moteurs.  Un  nombre  important  de  commandes.  dont  certalnas  sont  multlplexAas,  Aquipent  la 
manche  at  la  manette.  ParmI  celles-cl  : 

•  un  joy-stick  parmat  la  dAplacement  d'una  alidade  sur  toute  la  surface  das  trols’  visualisations.  La  sAlactlon 
das  options  ou  paramAtres  s'etfectue  par  appui  sur  la  joy-stick. 

•  un  poussoir  da  la  marietta  das  gaz  ast  utllisA  pour  la  modification  de  paramAtres  prAsentAs  sur  las 
visualisations. 

•  un  bouton  poussoir  joue  la  rOle  de  toume  pages  at  parmat  de  sAlectionner  las  diverses  pages  disponibiss  en 
VTL.  L'appel  das  pages  paut  Agalamant  s'effectuer  par  sAlaction  d'AtIquettes  au  joy-stick. 


3.2  INTEGRATION  DU  DIALOGUE  VOCAL 

L'implantatlon  du  dialogue  vocal  pour  TexpArlmanlation  sur  la  RAFALE  A  fait  I'objet,  aux  AMD-BA,  de 
nombraux  travaux  amont  affectuAs  avac  CROUZET  at  soutenus  par  las  Services  Otficiels  Franpals.  Parmi  ceux-ci, 
on  paut  citer  las  Atudas  rslatlvas  A  la  spAciflcotlon  das  performances  d'un  boitler  da  dialogue  vocal  A  mots 
enchalnAs  (soutlen  du  STTE)  at  las  Atudas  ralativss  A  I'ergonomie  das  commandes  IntAgrAes  manuelias  at 
vocales  (soutlan  de  la  DRET).  L'appllcation  prAsentAe  lei  est  Issue  de  cas  travaux  at  serf  da  base  A  la  dAfinItion 
vocals  du  RAFALE. 

Par  ailleurs  das  vols  spAcIflques  sur  un  Mirage  III  sont  an  eours  au  Centre  d'Essais  en  Vol  (CEV)  de  BrAtlgny 
pour  la  miss  au  point  das  divers  algorlthmaa  de  reconnaissance. 
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L'iquIpanMnt  deiUni  aux  axpirtmenlatlona  lur  I'avlon  RAFALE  eat  un  boWar  3/8  ATR  rteUte  par  la  cocIMd 
CROUZET  at  capabla  d'une  aynthdaa  vacate  at  d'una  raconnalasance  monolocuteur  8  moti  anchainds.  II  eat 
Implantd  an  aouta,  8  l'aiTi8re  du  poala  da  pUataga.  II  oat  connactd  au  bua  numdrlque  at  une  llalaon  apdcUlque. 
acceaalble  du  tndcanlden  da  plate,  parmat  da  tdldetianiar  laa  tdldrencei  vocalea.  En  cablne,  un  altamot  d8dl8  au 
dialogue  vocal  aa  altua  aur  la  polgnda  da  mancha.  Un  Intarruptaur  altu8  aur  la  banqualta  drolte  pennet  da 
conAgurar  la  Boitiar  da  Dialogue  Vocal  an  mode  apprantlaaaga,  vdittlcation  ou  modification. 

3.2.1  REOLES  OENERALES 

Pour  reater  homogdna  avec  la  ddflnition  da  la  cablna  du  RAFALE,  I'application  vocale  utiliae  I'Anglaia 
comma  langue  auaal  bien  pour  la  commando  qua  pour  la  aynth8ae  vocale.  L'emploi  d'une  langue  8trang8re 
conatitue  une  difficultd  dana  la  mesure  oil  le  locuteur  na  prononca  pax  laa  mota  de  fapon  conatante.  Une  Idgdre 
ddgradation  dex  partonnancex  a  dtd  conatatda,  au  aol,  pour  certains  pilotes. 

Compte  tenu  qua  lea  diffdrenta  didmants  Intervenant  dans  le  dialogue  pilote-systdme  peuvent  agir  de  facor. 
Inddpandante,  II  a  dtd  ddcidd,  dans  un  but  de  slmpllflcation,  de  ne  pas  autorlsar  un  ddbut  de  modlflcotion  8  la 
voix  at  un  achdvement  par  un  autre  moyen  de  commands  diaponlMe  en  cablne  et  vice-versa. 

Un  retour  systdmatlque  et  sans  ambigultd  du  rdsultat  de  chaque  commande  dnoncde  8  la  voix  est  rdalisd.  Ce 
retour  est  homogdrw  8  celul  exiatant  pour  las  commandas  classiquas  et  fait  appel  essantiellement  aux 
visualisations. 

Pour  amdliorar  I'ergonamie  das  dnoncds  vocaux,  II  ne  figure  pas  de  mot  eld,  du  type  'ENTREE',  pour  vallder 
ou  confirmer  une  commando.  Par  contre.  le  pllote  a  la  possibllltd  d'annuler  la  demidre  commande  vocale  emise 
et.  sur  demande,  d'entendre  par  synthdsa  vocale  le  dernier  mot  cld  reconnu 

Dans  las  applications  ddveloppdes,  la  majorlte  des  commandos  enonedes  a  la  voix  reprend  les 
commmandes  classiquas  dd|8  existantes.  Ceilas-ci  concement  : 

•  la  modification  des  paramdtres  modifiables  par  le  Paste  de  Modification  de  Paramdtres  (P.M.P.). 

•  la  ddslgnatlon  des  Miquettes  situdes  sur  les  pages  prdsentdes  en  VTM  et  en  VTB. 

•  la  sdlectlon  d'optlona  prdsentdes  en  VTH,  ou  en  VTM.  ou  en  VTB. 

•  la  sdlectlon  du  mode  approche. 


3.Z.2  POSTS  DE  MOOIHCATION  DE  PARAMETRES 

L'ensemble  des  paramdtres  modifiables  au  P.M.P  est  reprts  8  la  voix.  Cependant.  le  changement  de  la 
frdquence  ou  du  canal  des  posies  UHF  et  V/UHF  s'elfectue  par  le  mdme  mot  cld.  La  distinction  du  canal  ou  de  la 
frdquence  se  fait  au  niveau  du  nombre  de  cbifires  dnoncds. 

Par  rapport  aux  commandes  classiquas,  la  possibllltd  de  modifier  dgalement  un  but  de  destination  par  son 
indicatif  est  envisagda.  C'est  un  moyen  qui  d^^e  la  mdmoiisation  du  numdro  du  but.  II  ast  alnsi  plus  alsd 
d'dnoncer  'DEST  INDIA  TANGO  ROMEO',  pour  la  sdlectlon  du  but  relatlf  8  Istras  (ITR)  ou  'DEST  ISTRES'. 

La  visualisation  de  chaque  paramdtre  P.M.P,  en  cours  de  modification  par  la  voix,  est  effectude  sur  la 
visualisation  tdte  haute  de  tapon  fugitive. 


3.2.3  DIALOGUE  AVEC  LES  VISUALISATIONS 

Le  dialogue  avec  les  visualisations  comprend  la  ddslgnatlon  des  etiquettes  situdes  en  bandeau  sur  les  pages 
prdsentdes  en  VTM  ou  en  VTB  et  la  sdlectlon  d'options  permettant  entre  autres  la  modification  de  la  valeur  de 
certains  paramdtres. 

L'emploi  de  la  commande  vocale  parmat  I'appel  direct  des  pages  prdsentdes  en  VTM  ou  en  VTB.  Ces  pages 

sort 

•  En  VTB  ; 

•  la  page  Hate  des  pannes. 

•  la  page  moteur. 

•  la  page  carburant. 

•  la  page  divers. 

•  le  page  navigation  mode  ROSE. 

•  EnVnil; 

•  la  page  Hate  des  buts. 

•  la  page  way-point, 

•  la  page  recalage. 

Ouelles  que  aoiant  les  pages  prdsentdes  en  VTM  et  en  VTB.  II  est  possible  de  sdlecter  ou  de  ddsdiecter  8  la 
voix  les  options  sulvantes  : 

•  le  guidage  en  vHesse  sur  le  but  de  deatlrurtlon, 

•  la  navigation  enchalnde, 

•  le  but  auxiliaire, 

•  un  way-point, 

•  la  frdquence  VOR. 
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Oe  mdme  que  pour  le  but  de  destination,  I'appel  d'un  way  point  ou  d'un  but  auxlllaira  pout  Mrs  realise  4  la 
voix,  par  son  numdro  ou  par  son  IndlealH.  Le  rndme  mot  dd  est  utlllsd  dans  les  deux  cas. 

En  page  navigation  en  VTB,  11  asl  possible  d  la  voIx  : 

•  de  vIsuaUsar  at  de  modWer  le  but  compldmantalrs  par  appel  d'un  numdro  de  but. 

•  de  modHIer  le  but  compldmentalre  par  appel  de  son  indicatif. 

•  de  prdsenter  ou  de  na  pas  prdsentar  la  course. 

•  de  modifier  la  valaur  de  la  course, 

•  d'alfictier  ou  de  ne  plus  alficher  la  route  ddsirde  du  but  de  destination. 

•  de  visualiser  le  VOR. 

Toutes  les  options  ou  paramdtres  cltds  cl-dsssus  ne  peuvent  dtre  modifies  qu'en  page  navigation.  Si  une 
modification  par  la  voix  est  damandde  sans  que  la  page  navigation  soH  prdsente.  un  message  vocal  spdcHie  que 
la  page  prdsantde  n'est  pas  la  bonne  et  que  par  consdquenl  I'ordre  dmis  ne  peut  pas  dtre  pris  en  compte. 

•  En  VTH  : 

En  tdte  haute,  flgurent  deux  dchalles,  une  pour  I'lncldance  et  une  pour  le  iacteur  de  charge.  La  visualisation 
ou  la  non  visualisation  de  chaqua  dchelle  peut  dtre  demandde  d  la  voix  et  le  mdme  mot  cld  que  celul  ayant  servi 
d  rappel  de  I'dchelle  est  dnoncd  pour  la  talre  disparahre. 


3.2.4  MODE  APntOCHE 

La  adlactlon  ou  la  ddsdiection  du  mode  approche  peut  dtre  executda  d  la  voix. 


3.2.S  SYNTHESE  VOCALE 

La  synthdse  vocals  est  utilisde  en  permanence  pour  les  retours  des  diagnostics  de  reconnaissance  et  pour 
les  contrdlas  de  cohdrence.  Les  retours  de  diagnostics  sont  propres  d  la  reconnaissance  vocale  et  sont  du 
type  :  “TOO  LOUD'.  *100  LOW',  "TOO  LONG'  et  'REPEAT'. 

La  notion  de  contrdle  de  cohdrence  est  apparue  ndcessaire  au  cours  des  simulations  pour  indiquer  de  fapon 
explicite  la  raison  pour  laquelle,  blen  qu'une  commands  soH  correctement  reconnue  par  le  BOV,  elle  n'dtait  pas 
prise  en  compte  par  le  systdme.  Les  contndles  de  cohdrence  ont  pour  but  de  vdiifier  que  la  commands  dnoncde 
d  la  voix  est  compatible  d  I'Instant  donnd  avec  I'dtat  du  systdme  ou  que  le  format  et  la  structure  de  I'dnoncd  sont 
an  accord  avec  ceux  attendus  pour  cede  commando.  Un  exemple  des  dnoncds  des  contrdles  de  cohdrence  est 
donnd  ci-aprds  : 

«  'WRONG  CHANNEL'  :  Si  le  numdro  du  canal  radio  UHF  ou  V/UHF  n'est  pas  compris  enfre  1  et  20. 

•  'WRONG  FREQUENCY'  :  SI  la  frdquence  n'est  pes  une  frequence  UHF.  V/UHF  ou  VOR/ILS. 

•  'NO  POINT*  :  SI  I'indicatif  du  but  dnoncd  a  la  voix  ne  correspond  pas  d  un  but  renseignd  en  mdmoire. 

•  'MULTI  POINTS'  :  Si  I'indicatif  du  but  est  incomplet  et  qu'll  y  a  ambiguitd  sur  le  choix  du  but. 

•  'REPEAT'  :  Si  le  nombre  de  digits  rdellement  compris  est  incohdrsnt  par  rapport  au  nombre  attendu. 

•  “WRONG  PAGE'  :  SI  la  commande  est  incompatible  avec  I'dtat  des  visualisations. 

•  etc. 


3.3  ALARMES  VOCALES 

Dds  le  premier  vol,  le  RAFALE  dtalt  dquipd  d'un  boltler  d'alarmes  vocales  permettant  d'dnoncer,  apres  un 
message  sonote,  un  message  vocal  indiquant  de  fapon  expllcRe  I'origine  de  I'alarme.  Une  gestlon  des  prloritds 
est  efldctude  afin  d'dvtter  toute  corrfuslon.  Lorsque  plusleurs  alarmes  de  mdme  priorltd  apparaissent,  les 
messages  vocaux  sont  entrelacds  et  sont  dnoncds  jusqu'd  ce  que  le  pilots  interrompe.  de  ta^n  volontaire, 
I'dnoncd  de  ces  messages. 

4.  SIMULATIONS 


Une  fbis  I'appiicatlon  vocale  ddfinie,  des  simulations  ont  did  rdalisdes  au  centre  d'essais  das  AMD-BA  d 
Istrss,  sur  OA.S.I.S.  (Outll  d'Aide  d  la  Spdcificatlon  d'lnformations  Systdme).  “Des  simulations  sont  eftoctudes 
dans  une  cablne  ou  I'interMce  pllote-systdme  est  reprdsentatlve  de  cells  de  I'evion  RAFALE.  Les  travaux  mends 
avec  CROUZET,  soutenus  par  le  STTE  et  la  DRET,  ont  permis  d'investiguer  plusleurs  domaines  el  en  partlculier 
sur  : 

•  I'accoutumance  d  la  reconnaissance  vocale, 

•  I'apport  das  commandes  dnoncdes  d  la  voix. 

•  I'ergonomie  des  commandes  dnoncdes  d  la  voix. 
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4.1  ACCOimiMANCE  OES  LOCUTEURS 

Lea  diversas  simulations  sRsctutes  sur  OA.S.I.S.  montrsnt  qu'une  accoutumance  des  locuteurs  novices  est 
indispensable  pour,  d'une  part  mbmorlser  le  vocabulaire  el  sa  syntaxe  associto,  et  d'autre  part,  pour  maitrlser 
I'blocution  ofln  que  celle-cl  soit  comprdhansibts  du  dlsposHlf  de  dialogue  vocal.  Trois  phases  distinctes  sont 
Identlfibes : 

•  initiation  au  fOnctionnement  du  dialogue  vocal, 

•  essais, 

•  fonctionnement  opdrationnel. 

4.1.1  Initfartion  au  tewcMotmemenl  du  dialague  woeal 

Cette  phase  est  enectute  sans  couplage  4  la  simulation  et  permet  au  pilots  de  se  familiariser  avec  le 
fonctionnement  de  la  commande  vocals  (creation  des  rMbrences,  dlocution,  appui  altemat...).  Quelques  essais 
de  reconnaissance  sont  affectu4s  sur  un  vocabulaire  rMuit  d'environ  20  mots.  Ces  essais  permsttsnt  de  trouver 
raiocutlon  la  plus  appropride  pour  une  bonne  reconnaissance,  la  mellleure  dtant  uns  diocutlon  naturelle,  tranche 
el  sans  hesitation.  Pendant  cette  phase,  les  rtaultats  de  reconnaissance  sont  gdndralement  falbles  par  manque 
de  Constance  dans  I'dlocution. 

4.1.2  Eaaala 

Lore  de  cette  phase,  I'apprentissage  complet  du  vocabulaire  de  I'appilcation  commande  vocale  est  effectud. 
Le  locuteur  s'exerce  a  prononcer  les  messages  autsi  naturellement  que  possible  atin  d'obtenir  des  performances 
acceptables  (environ  90  %  de  taux  de  reconnaissance).  Un  essai  est  compose  d'une  centaine  de  phrases 
syntaxiquemant  comctea. 

Plusteurs  iterations  sont  ndcessalres  pour  ddpasser  un  seuil  au-deld  duquel  II  est  envisageable  de  coupler  le 
dialogue  vocal  avec  des  simulations,  le  nombre  d'iterations  etant  fonction  du  locuteur. 

4.1.3  FoncUonnement  operationnal 

La  seuil  de  performance  d'environ  90  %  etant  attaint,  les  references  vocales  du  pilots  sont  quasi-definitives. 
L'appllcation  vocale  eat  alors  couplde  aux  simulations  de  I'avion  Le  pilots  se  familiarise,  s'il  ne  I'est  pas.  avec 
I'utlllsation  des  dlfferentes  commandos  executees  i  la  voix  et  avec  leurs  effets  sur  le  systems  (emplacement  des 
retours  visuals,  accoutumance  aux  retours  par  synthese  vocale,  configuration  des  autres  commandes,  ...). 

La  representation  sulvante  donnent  une  idde  de  revolution  du  taux  de  performance  en  fonction  du  nombre 
d'essals  et  done  de  I'accoutumance  pour  I'ensemble  des  experimentateurs. 


parformsnes 
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4.2  APPORTDES  COMMAHDES  ENONCEES  A  LA  VOIX 

Au  cours  des  timulations,  un  certain  nofflbre  d'avis  aubjactlfs  sur  I'apport  du  dialogue  vocal,  ont  Md 
racueillis  auprta  des  pilotea.  Ces  avis  ont  did  corrdids  avac  las  rdsultats  oMenus  par  un  outil  d'dvaluation, 
objactlf,  vlaant  d  donnar  des  intormations  sur  la  charge  da  travail.  La  mise  an  oeuvre  da  cat  outil  n'est  pas 
deaUnde  d  I'oMention  d'una  valaur  quantitative  absotue  da  la  charge  da  travail.  Ilde  d  I'emplol  de  telle  ou  telle 
commande,  compte-tanu  du  (alt  qua  la  notion  de  charge  de  travail  sat  diflicllament  apprdhendable  dans  la  cadre 
partlculier  des  simulations  effactudas. 

L'dvaluation  de  cat  outil  a  did  rdalisde  sur  un  profll  de  mission  ddfini  d  priori  at  sur  leoual  de  nombreuses 
commandes  devaicnt  etre  exdcuteas.  Cette  mission  comporle  six  sagmems  . 

1 .  ddcollage  at  montde  d  10  000  ft. 

2.  palier  d  10  000  ft. 

3.  dascente  jusqu'd  400  ft. 

4.  suivi  de  terrain  at  panne  grave, 

5.  ddroutement, 

6.  atterrissaga  sur  un  terrain  de  recuail. 

La  charge  de  travail  est  estlmde  d  i'alde  deux  mdthodas  similalres  faisant  appal  d  une  tdche  secondalre. 
Celte-cl  consiste  d  appuyer  de  (aeon  rdgulldre  sur  un  Interruptaur  tout  an  assurant  la  tdche  principals  de 
pilotage.  Las  deux  mMhodes  d'estimatlon  de  la  charge  de  travail,  sont  ddrivdes  du  'Time  Estimation  Standard 
Deviation'  at  du  'Tapping  Rhythm  Task'  (1). 


4.2.1  TIME  ESTIMATION  STANDARD  DEVIATION 

Tout  an  rdalisant  la  tdche  principale  de  gestion  de  la  mission,  la  pilots  entend  de  (aeon  cyclique,  toutes  las 
20  sacondas,  un  son  d'une  durde  d'une  seconds  si  de  (rdquence  750  Hz.  Dds  qua  le  pilote  entend  ce  son,  11 
eftectue  un  appul  sur  une  pddale  situde  sous  son  pled  droH.  Ensulte,  tout  an  continuant  la  tdche  principale,  II 
effectue  un  deuxidme  appul  sur  la  pddale,  au  bout  d'un  temps  estimd  de  dix  secondss.  Blen  entendu.  pendant 
I'essai  touts  rdtdrence  de  temps  de  Tordre  de  la  seconds  est  supprimde  (pas  de  montre). 

A  I'orlgine,  la  mdthode  du  Time  Estimation  Standard  Deviation  utilise  pour  I'appul,  un  bouton  situd  sur  la 
manette  des  gaz.  Etant  donnd  que  pour  mener  d  blen  sa  mission,  le  pilote  dispose  de  commandes  temps  rdel 
sltudes  sur  le  manche  et  sur  la  manette  des  gaz,  Torgane  d'appui  a  dtd  ddportd  vers  les  pleds,  afln  de  libdrer  Is 
main  du  pilote,  au  cas  oil  des  commandos  temps  rdel  seraient  ndeessaires  d  raccompllssement  de  sa  mission. 

La  mdthode  consiste  d  recuellllr  les  dcarts  de  tamps  par  rapport  aux  10  secondes  estimdes  et  a  en  calculer 
Tdcart  type.  CecI  donne  une  estimation  globale  de  la  charge  de  travail  au  cours  de  la  mission. 


4.3  TAPPING  RHYTHM  TASK 

Cette  mdthode,  trds  voisine  de  cells  ddciite  prdeddemment,  consiste  d  taper  aussi  rdgulidrement  que 
possible  sur  la  pddale  d  un  rythme  d'un  appul  toutes  les  deux  secorrdes.  Les  dcarts  entre  deux  appuis  successKs 
sont  analysds  et  servent  d  calculer  une  valeur  globale  pour  le  vol.  L'dvaluation  de  cette  mdthode  aux  Etats  Unis, 
mit  en  evidence  que  le  rythme  dtalt  (ortement  perturbd  lors  des  ajustements  de  la  manette  des  gaz,  le  bouton 
d'appui  dtant  situd  sur  celle-cl.  Des  Intervalles  de  temps  supdrieurs  d  5  secondes  dtalent  observes.  Comme  pour 
le  'Time  Estimation  Standard  Deviation',  les  simulations  rdallsdes  sur  OASIS  s'eftectuent  avec  I'organe  d'appui 
ddportd  au  niveau  du  pled  droit,  dvitant  ainsi  ce  probldme. 

4.3.1  M»E  EN  OEUVRE  DE  CES  METHOOES 

Les  mdthodes  du  Time  Estimation  Standard  Deviation  et  du  Tapping  ne  donnent  qu'un  rdsultat  global  de 
Testimatlon  de  la  charge  de  travail  au  cours  de  le  mission  et  ne  permettent  pas  d'identlfler  les  Instants  critiques 
lors  du  ddroutement  de  la  mission.  Pour  cela,  des  diagrammes  sont  dditds.  En  partlculier  un  dlagramme  altitude  - 
temps  sert  de  point  de  repdre  rapide  et  permet  d'identlfler  les  dlffdrents  segments  de  la  mission  et  un 
dtagramme  dcart  de  temps  -  temps  comports  les  relevds  d'dcart  de  temps  par  rap|>ort  au  temps  dcould.  Ce 
dernier  permet  d'identlfler  rapidement  et  prdcisdment  las  zones  oil  la  charge  de  travail  est  importante.  Ces 
diagrammes  ont  I'allure  suivsnte  : 


S«ul«  la  m^thode  du  Tapping  a  Mt  rainnue  aprta  Evaluation  par  doa  axpErtmentalaura  at  daa  pilotaa.  Catta 
mEthoda  ast  |ugEa  plua  soupla  d'amplol  at  prEaante  par  alllaurs  I'avantage  da  pannettra  une  analyia  plua  fina 
daa  rEaultata.  La  majaura  paitia  daa  almulationa  a  done  EtE  alfactuEa  avac  la  mEthoda  du  Tapping. 

Una  Evaluation  pour  un  axpErimantataur  donnE  comporta  ayatEmatlquamant  daux  almulationa,  una  aana 
dlalogua  vocal  at  una  avac  dialogue  vocal.  Lea  rEaultata  aont  anauita  comparEa  an  ralatff  au  nivaau  daa  courbaa. 


Laa  courbaa  obtanuaa  font  apparaltra,  dana  lea  deux  caa,  daa  valeura  extrEmea  mala  unlquement  maximalea. 
CacI  a'expllgua  par  la  talt  qua  naturellement,  lore  da  ptiaaea  critiquea,  la  pErtode  daa  battemanta  augmente. 
L'Ecart  maximal  eat  alora  EcrEtE  E  5  a.  Caa  extrEmea  aont  aurtout  conatatEa  lore  daa  pErtodea  cribquaa,  par 
example  lore  da  la  panne  aurvenua  an  aulvi  da  tarraln.  L'analyaa  daa  diagiammea  Mt  Egalamant  apparidtre  daa 
maxima  E  ctiaque  tranaition  ou  manoeuvre  dEficate,  par  example  au  moment  da  la  fln  da  la  deacante  at  da 
I'enclenchamant  du  aulvi  da  terrain.  Par  aillaure.  compta-tanu  da  la  aanaiblIttE  da  catta  mEthoda,  11  a'avEre 
qu'alle  na  paut  Etre  utlllaEe  etflcacament  al  I'expErimantataur  ne  maltrlaa  paa  patMtament  I'avion  (aymbologie, 
procEdurea,  commandaa,...)  at  la  commande  vocala.  Toua  lea  locuteure  axpErtnrantataure  Etaient  done 
accoutumEa  E  la  raconnalaaance  vocala. 


L'analyse  das  courbat  da  Tapping  parmat  da  constatar  qua  das  zonas  da  forla  parturbation  subsistent 
malgrb  I'amplol  du  dlalogua  vocal,  an  particuliar  aprbs  la  panna  at  lors  da  I'attarrissaga.  Cas  points  ont  tail 
I'oblst  d'un  compidmant  d'application  vocala  an  charchant  una  amdiloration  du  dlalogua  pllota-systdme. 

L'appllcatlon  vocals  ddveloppda  jusqu'd  prdsant  ne  faM  appal  qu'd  das  commandos  dltas  da  "bos  nivoau'.  En 
aflat,  chaquo  commando  vocals  ost  una  rsprisa  pure  ol  simpis  das  commandos  classiquss  sxistant  dd|d  dans  la 
cabine. 

Cspandant,  la  dialogue  vocal  est  un  moyan  beaucoup  plus  puissant  permettant,  par  una  simpis  commando 
gdndriqus.  da  ddclenchar  das  prociduros  connuas  du  systdma  at  qui  correspondent  d  da  multiplos  actions 
didmentairos.  On  axampla  typiqus  d'une  tolle  commands,  dits  do  'haut  nivoau",  qua  I'on  ponss  appllqusr  sur  la 
RAFALE,  ost  la  notion  do  fiches  relatives  aux  terrains  d'atterrtsaage. 

Cas  Aches  sont  ronsoigndas  au  sol  at  concornent  tous  las  terrains  pris  en  compte  lots  da  la  preparation  da 
mission.  Dos  modiflcations  minoures  pouvenf  dtra  apportdes  en  cours  da  vol.  Tous  las 
systdme  at  contenus  dans  la  Ache  sont  pris  on  compte  lors  da  I'dnoncd  d'une  commando  du  type  APPROACH 
ISTRES'  qui  sdlectlonne  dgaloment  la  mode  approche. 

Las  commandos  da  'haut  nivoau"  apportont  ainsi  una  souplesse  d'emplol  at  un  gain  opdrallonnnel  trds 
apprdclable  lors  da  phases  da  vol  ndcessitant  romplol  do  nombreusos  commandos.  Co  type  da  commando  est  do 
nature  d  diminuar  trds  fortomant  la  charge  da  travail  du  pilote. 

5.  CONCLUSIONS 

L'introduction  da  nouvelles  technologies  dans  la  cabine  d'un  avion  d'armes  comma  la  visualisaAon  tdte 
haute  d  opAque  diflractive,  la  visualisation  tdte  moyenne  collimatde  at  la  dialogue  vocal  constAue  una  dvolutlon 
Importante  dans  la  conception  da  rinterface  pilote-systdma. 

La  dialogue  vocal  destind  aux  avions  d'armes  est  un  produit  da  trds  haute  technologle  qua  peu  da  pays 
maflrisent.  A  travsrs  la  monde,  das  essais  an  vol  prennent  place  sur  divers  typos  d'appareils  afln  do  prdparer 
l'introduction  d'un  tel  dispositif  sur  las  avions  das  prochalnes  ddcennies.  L'expdrimentatlon  du  dialogue  vocal  d 
bord  du  RAFALE  s'inscrit  dans  ce  cadre  Id.  Blan  entendu,  das  progrds  restent  d  faire  dans  ce  donwine  pour 
atteindre  un  dtat  ou  la  reconnaissance  sera  multl-locuteurs  avec  das  performances  proches  da  100  %. 

Ndanmolns,  I'lirtroductlon  du  dialogue  vocal  tal  qu'il  existe  aujourd'hul  reprdsente  un  gain  opdrationnel  trds 
apprdclable  notammerrt  lors  da  I'utilisation  da  commandos  da  haut  niveau.  II  ne  constitue  pas,  cepandant.  una 
solution  miracle  aux  probldmes  da  I'interface  pilote-systdma  et  11  convient.  an  particuliar.  da  I'utiliser  dans  son 
domalne  d'application. 

Sur  la  base  das  travaux  prdsantds,  la  ddAnition  da  la  cabine  das  avions  RAFALE  das  anndes  95  intdgre 
d'ores  et  ddjd  un  dispositif  da  dialogue  vocal  associd  d  da  nouveaux  moyens  da  commande.  La  dialogue  vocal 
jouera  un  rble  importartt  et  permettra  da  disposer  d'une  Interface  pllote-systume  adaptde  aux  mission  las  plus 
contreignantas. 
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6.  ABREVIAHONS 

AWMA  :  Avion*  Marcel  OasaauH-Breguel  Aviation 
BDV  :  Bottler  de  Dialogue  Vocal 

CEV  :  Centre  d'Essals  en  Vol 

ORET  :  Direction  des  Recherche*,  Etudes  e(  Techniques 

MS  :  Main*  sur  Manche  et  Manette 

DAWS  :  Outll  d'Alde  A  la  Specification  d'lnformations  SyslAme 

PMP  :  Posle  de  Modification  de  Paramfitres 

SNA  :  Systdme  de  Navigation  et  d'Attaque 

STTE  :  Service  Technique  des  Telecommunications  et  des  Equipements  aeronautiquas 
VTH  :  Visualisation  Tfite  Haute 

VTM  :  Visualisation  Thte  Moyenne 

VTL  :  Visualisation  Tdte  Laterals 
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Abstract 


This  paper  documents  the  application  of  Systea-Wide  Integrity  Management  (SWIM)  to  the 
F-16  Terrain  Following  (TP)  system  in  order  to  maximize  flight  safety  during  TP  opera¬ 
tion.  The  architecture  of  the  F-16  TP  system  is  presented  and  areas  are  identified 
where  conventional  self-test  Is  not  sufficient  to  ensure  flight  safety.  The  concept  of 
system-wide  monitoring,  or  SWIM,  is  discussed  and  the  SWIM  development  process  used  for 
P-16  TF  is  reviewed.  In  addition,  the  SWIM  features  developed  for  the  F-16  TF  system 
and  the  safety  benefit  and  cost  effectiveness  of  these  safety  enhancements  are 
discussed . 
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Background 

The  Halted  room  for  on-board  equipaent  in  modern  fighter  aircraft  has  led  to  the 
mechanization  of  advanced  fllght-critical  functions  with  nonredundant  elements.  For  the 
P-l6y  such  space  limitations  led  to  the  mechanization  of  a  TP  system  with  multiple  non> 
redundant  sensors  and  control  processors.  In  spite  of  lacking  redundancy  In  critical 
subsystems,  flight  safety  concerns  required  that  fault  tolerance  had  to  be  achieved  in 
the  overall  TP  system.  As  a  result,  development  of  the  P-16  TP  system  was  accomplished 
with  an  advanced  flight  safety  enhancement  technique  —  System-Wide  Integrity  Management 
(SWIM).  SWIM  is  a  new  approach  to  both  the  design  and  utilization  of  in-flight  built-in 
test  (BIT)  to  detect  otherwise  undetectable  malfunctions  that  could  result  in  the  loss 
of  an  aircraft.  The  SWIM  technique  was  first  developed  by  General  Dynamics  for  the  Ad¬ 
vanced  Fighter  Technology  Improvements  (APTI)  Program  for  the  Automated  Maneuvering  At¬ 
tack  System  (AMAS).  The  SWIM  technique  was  then  applied  to  the  F-l6  TF  system.  Detec¬ 
tion  of  flight-critical  malfunctions  by  SWIM  is  followed  by  an  automatic  recovery  maneu¬ 
ver,  which  consists  of  a  roll  to  wlngs-level  fly-up  for  the  F-l6  TF  system. 


P-16  TF  System  Overview 


TF  System  Components 

The  F-16  TF  system  provides  the  capability  to  fly  low  level  during  day,  night,  or 
adverse  weather  conditions  at  a  fixed  offset  over  terrain  within  aircraft  and  crew  ac¬ 
celeration  constraints.  Design  of  the  F-l6  TF  system  required  the  integration  of  multi¬ 
ple  subsystems,  as  depicted  in  Figure  1.  The  TF  system  generates  climb/dive  (C/D)  com¬ 
mands  based  on  returns  from  terrain  sensors  and  aircraft  state  sensors.  These  commands 
are  then  either  coupled  into  the  F-l6  flight  control  system  for  Auto  TF  or  displayed  to 
a  pilot  for  manual  terrain  following  (MTF).  The  system  Is  comprised  of  multiple  sen¬ 
sors,  processors,  and  displays,  as  shown  in  Figure  2.  A  brief  description  of  the  TP 
subsystems  is  provided. 


•  Fonimrd-Looking  Radar  lensas  Ibrroln  and  Aaaadatad  Computar 
Qanaratat  CNmb/DIva  Cemmanda 


«  FHQlit  Control  Systam  CommaiHla  A/C  Btota  Clianoa  Baaad  on 
Commanda  from  Radar  Computor 
—  Oireet  Ccwpllnq  in  Autamatle  Terrain  FoWowIng  (TF) 

~  Control  Mdi  Coupling  of  Plipliyrd  Command*  In  Manual  TF 

•  Subayatama  Faadback  Changing  A/C  Btota  for  Command  Nulling 
and  Radar  Sean  StaMHzatlon 

•  Radar  AMmatar  Centrota  A/C  Ovar  Low  Back-Scattar  Tarraln  and 
Chacfca  Oparatlon  During  Forward-Looking  Radar  Control 

Figure  1  Ibrraln  Following  Requires  Integration  of  Multiple  Subsystems 


LANTIFtN  NAVIQJCnON  POO  15538  MUX  BUS 


Figure  2  F-1S  TF  Systsm  Architecture 
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Low  Altitude  Navigation  and  Targeting  Infrared  for  Night  (LANTIRN)  Navigation  Pod. 
The  LANTIRN  navigation  pod  consists  of  two  prlaary  subsystems:  the  forward  looking  in¬ 
frared  (FLIR)  and  the  terrain-following  radar  (TPR).  The  PLIR  provides  a  visible  repli¬ 
ca  of  the  terrain  forward  of  the  aircraft  at  night.  The  PLIR  Is  not  part  of  the  TP  sys¬ 
tem  command  loop,  but  is  used  as  a  night  aid  for  pilot-controlled  flight.  The  TPR  is 
the  primary  sensor  for  the  TP  system  and  provides  the  computations  for  the  TP  system 
commands.  The  TPR  scans  the  terrain  in  front  of  the  aircraft  and  inputs  the  scanned 
terrain  range  and  angle  to  a  command  algorithm,  which  utilizes  Inputs  from  other  TP  sub¬ 
systems  to  generate  C/D  commands. 

Inertial  Navigation  System  (INS).  The  INS  provides  the  platform  velocities  and 
coordinates  suppll^  to  the  navigation  pod  to  stabilize  the  TPR  antenna  scan  and  to  cal- 
^'ulate  the  aircraft  flight  vector  for  use  in  C/D  command  nulling. 

Combined  Altitude  Radar  Altimeter  (CARA).  The  down-looking  CARA  is  used  to  provide 
C/D  commands  whenever  the  terrain  reflectivity  is  too  low  for  the  forward-looking  TPR  to 
receive  sufficient  energy  for  terrain  detection,  such  as  over  water.  CARA  Is  also  used 
as  an  independent  check  of  the  forward-looking  TPR  operation  to  detect  TPR  or  INS  Input 
angle  errors  that  result  In  fly-low  errors.  These  fly-low  errors  would  be  detected  by 
the  CARA  as  over-flown  terrain  peaks  that  were  clipped  too  closely,  preventing  a  poten¬ 
tial  TFR-controlled  clobber.  The  prevention  of  a  potential  TPR-conirolled  clobber  would 
result  since  the  CARA-based  check  of  TPR-controlIed  flight  compares  radar  altitude  to  75 
percent  of  the  TP  set  clearance  with  an  automatic  fly-up  manuver  being  triggered  if  ter¬ 
rain  peaks  are  approached  closer  than  the  75  percent  threshold. 

Multifunction  Display  (MFD).  A  radio  frequency  (RP)  energy-based  confidence  dis¬ 
play  called  an  E-Squared  display  is  provided  on  the  MFD.  This  display  uses  raw  TFR 
video  to  depict  terrain  changes  in  real  time.  In  fog  or  rain,  when  PLIR  information  is 
unavailable,  the  pilot  can  monitor  aircraft  climb  or  dive  commands  with  this  display. 

Head-Up  Display  (HUD).  TF  C/D  commands  are  provided  on  the  HUD  by  the  TF  command 
box  symbol.  The  command  box  is  displayed  relative  to  the  aircraft  flight  path  vector 
marker,  providing  pilot  cues  for  C/D  command  nulling.  The  PLIR  visual  display  is  pro¬ 
vided  on  the  HUD  together  with  the  command  box. 

Central  Air  Data  Computer  (CAPO.  The  CADC  provides  barometric  altitude  for  use  in 
stabilization  of  INS  vertical  velocity,  which  Is  then  used  in  flight  vector  calculation 
for  the  C/D  algorithm. 

Fire  Control  Computer  (FCC) .  The  FCC  serves  as  the  bus  controller  between  TF  sub¬ 
systems. 

Stores  Management  b  >t  (SMS).  The  SMS  serves  as  the  backup  bus  controller  in  the 
event  of  an  FCt  railure. 

Global  Positioning  System  (GPS).  The  GPS  provides  Inertial  velocities  to  compare 
with  INS  velocities  for  INS  failure  detection. 

Digital  Flight  Control  System  (DFLCS).  The  central  part  of  the  DFLCS  is  the  quad- 
redundant  Digl^l  Flight  Control  Computer  (DFLCC),  The  DFLCC  interfaces  with  several 
flight  control  subsystems  in  a  redundant  fashion,  as  shown  in  Figure  3«  Failure  detec¬ 
tion  Is  achieved  by  multiple  cross-channel  voting  planes  Implemented  in  software. 
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All  flight-critical  flight  control  sensors  are  quad  redundant  and  are  input  to  each 
branch  of  the  DFLCC.  Discrete  inputs  are  also  connected  to  each  branch.  After  conver¬ 
sion,  the  input  values  are  then  cross-strapped  to  each  branch  through  a  digital  input 
plane.  Monitoring  at  this  point  allows  sensor  niscoopares  and  failures  to  be  identified 
without  falling  an  entire  branch.  The  data  links  consist  of  a  serial  digital  interface 
controlled  by  an  Input/output  controller  in  each  branch.  Each  branch  contains  one  data 
link  transmitter  and  three  receivers.  This  data  link  process  allows  each  branch  to  re¬ 
ceive  and  transmit  data  to  and  from  the  other  three  branches  asynchronously. 

Control  law  outputs  are  monitored  and  selected  in  software  by  each  branch.  Since 
the  four  branches  operate  asynchronously,  for  efficiency  Branch  B  is  always  used  to 
drive  the  Integrated  servoactuators,  which  in  turn  drive  the  control  surfaces. 


SWIM 

SWIM  Definition 

SWIM,  in  its  simplest  definition,  is  self-test  of  a  function  and  is  system-wide  in 
that  it  includes  all  individual  subsystems,  interfaces,  and  relevant  internal  and  exter¬ 
nal  Influences  on  the  total  architecture  involved  in  that  function  (left  circle  of  Fig¬ 
ure  4).  The  system-wide  aspect  of  SWIM  becomes  very  large  if  the  associated  function  is 
of  a  global  nature  —  as  in  the  case  of  F-l6  flight,  which  involves  all  major  aircraft 
subsystems.  Including  engines  and  flight  controls.  A  reliable  communications  medium, 
such  as  a  high-speed  multiplex  bus,  is  required  among  all  involved  components.  With 
present  technology,  the  concept  can  be  extended  to  less  global  functions  such  as  AMAS 
and  TF.  SWIM  can  be  thought  of  as  an  expanded,  traditional  (single  black  box)  self-test 
that  operates  as  a  system-level  monitor  to  detect  critical  subsystem  failures  and  verify 
system  functional  integrity  (as  in  the  center  circle  of  Figure  i|).  The  management 
aspect  is  applied  In  the  SWIM  design  phase;  it  Involves  the  elimination  of  a  safety  im¬ 
pact  associated  with  a  particular  subsystem  failure  rate  when  that  subsystem  has  minimal 
involvement  in  the  function  (as  in  the  right  circle  of  Figure  i4).  In  other  words,  the 
function  under  consideration,  TF  in  this  case,  has  certain  parameters  or  signals  that 
are  safety  critical  in  that  undetected  aberrations  in  these  signals  can  result  in  loss 
of  aircraft.  If  one  of  these  safety-critical  signals  is  involved  minimally  in  a  sub¬ 
system  or  simply  routed  through  that  subsystem,  then  SWIM  management  involves  designing 
the  SWIM  monitor  architecture  to  rely  on  an  alternate  route  or  bypass  for  that  signal  to 
ensure  detection  of  failures  in  that  subsystem  that  affect  the  critical  signal.  The 
safety  impact  of  that  particular  subsystem  is  then  effectively  bypassed.  The  bypass 
eliminates  safety  Impact  associated  with  failures  of  that  subsystem  since  failures  of 
that  subsystem  are  detected  by  comparison  with  an  alternate  source  of  the  same  signal. 


System-Wide  Integrity  Management 


FIgur,  4  Sy«t»nvWld«  Intogilty  Managenwnt 
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SWIM  Development 

To  develop  SWIM  for  the  P-16  TF  aysteo,  the  six-atep  approach  aummarized  in  Figure 
5  was  followed.  The  development  reaulted  in  the  quantification  of  the  safety  benefit 
and  the  cost  of  the  SWIM  features.  The  goal  was  to  implement  only  those  SWIM  features 
that  were  cost-effective  in  reducing  the  predicted  mishap  rate  for  F-16  TF. 


Figure  5  TF  Swim  Development  Approach 


The  first  step  in  the  SWIM  development  was  to  determine  the  signals  critical  to  TP, 
the  maximum  error  threshold  values  of  these  signals  that  could  be  tolerated  without 
safety  impact,  and  the  maximum  tolerable  delay  before  annunciation  of  these  threshold- 
exceeding  critical  signals.  The  second  step  was  defining  the  consequences  of  undetected 
critical  signal  failures,  and  the  third  step  was  to  determine  the  degree  of  safety  pro¬ 
vided  by  the  existing  self-test  provisions  of  the  TF  subsystems.  One  output  of  this 
analysis  was  the  rate  of  occurrence  of  undetected  hazardous  failures.  This  rate  was 
estimated  by  a  variety  of  analysis  techniques,  ranging  from  detailed  piece-part  failure 
modes  evaluations  to  the  analysis  of  system-level  failure  effects.  In  the  fourth  step, 
an  aircraft  safety  analysis  was  performed  to  predict  a  baseline  aircraft  mishap  rate  re¬ 
sulting  from  undetected  hazardous  failures.  The  safety  analysis  was  accomplished  using 
a  fault  tree  analysis  methodology,  which  models  many  effects  such  as  operational  usage 
and  pilot  response  to  failure  modes  in  order  to  obtain  the  most  realistic  prediction  of 
mishap  rates  practicable.  Once  individual  undetected  failure  modes  were  determined, 
SWIM  features  were  mechanized  to  provide  detection  capability.  Next,  the  aircraft 
safety  analysis  was  again  conducted  to  determine  the  mishap  rate  with  SWIM  features.  In 
the  fifth  step,  the  mishap  rate  with  the  SWIM  features  was  compared  with  the  baseline 
mishap  rate  to  obtain  a  measure  of  the  benefit  of  the  SWIM  features.  In  the  sixth  step, 
the  rough  design  for  the  SWIM  features  was  used  to  estimate  a  cost  for  the  features. 
The  cost  consisted  of  several  factors  —  including  schedule  impact,  estimates  of  software 
change  size,  and  risk  associated  with  development.  For  example,  the  attitude  estimator 
required  150  software  words  in  the  DFLCC,  had  demonstrated  low  risk  based  on  previous 
AMAS  use,  and  could  be  Implemented  relatively  quickly.  The  decision  as  to  which  SWIM 
safety  enhancements  to  Implement  was  then  made  by  the  Air  Force  based  on  projected  num¬ 
ber  of  aircraft  saved  and  coat  to  implement  the  SWIM  feature.  The  complement  of  SWIM 
features  selected  for  F-16  TF  required  approximately  2750  software  words  at  a  cost  of 
less  than  $2  million  to  achieve  a  predicted  aircraft  savings  of  approximately  $200  mil¬ 
lion  over  a  20-year  life  of  350  LANTIRN-equlpped  F-l6  aircraft. 

SWIM  Analysis  Results 


SWIM  Monitors 


Each  subsystem  involved  in  the  generation  of  TF  commands  was  evaluated  using  the 
SWIM  analysis  methodology.  It  was  concluded  that,  although  the  individual  TF  subsystems 
have  a  relatively  high  internal  self-test  coverage,  areas  exist  in  which  significant  im¬ 
provements  in  the  overall  TF  system  self-test  coverage  could  be  achieved.  Although  it 
was  not  feasible  to  develop  monitors  for  every  undetected  failure  mode  Identified  by  the 
analysis,  monitors  were  developed  for  the  failure  modes  that  contributed  the  major  por¬ 
tion  of  the  undetected  failure  mode  mishap  rate.  The  SWIM  monitor  features  required  a 
redundant,  cross-checked  host  with  enough  reserve  capacity  to  implement  the  features  in 
order  to  have  guaranteed  integrity  of  the  SWIM  features.  The  quad-redundant  DFLCC  pro¬ 
vided  the  required  host  for  the  SWIM  features.  In  Figure  6,  the  F-16  TF  SWIM  features 
are  listed  in  terms  of  the  basic  undetected  malfunction  causes  that  they  were  designed 
to  cover.  A  brief  description  of  the  critical  undetected  failure  mode  areas  and  the 
SWIM  features  designed  to  cover  them  follows. 
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SUBSYSTEM  PROCESSOR  MLURES 


Ftgura  6  F-16  TF  Swim  Features  . . .  Cover  Different  Undetected  Melfunctlone 


Sensor  Drift  and  Bias  Errors.  Table  1  contains  the  SWIM  features  designed  to  cover 
hazardous  drift  ^r  bias  error  salfunctions  of  the  INS  or  TFR.  Data  from  both  the  INS 
and  the  TFR  can  be  corrupted  by  drift  and  bias  errors  that  are  not  detectable  by  sub¬ 
system  self-tests.  In  the  case  of  the  INS,  monitors  were  implemented  that  could  detect 
these  errors  using  Independent  motion  reference  sources.  The  CPS  provides  a  highly  ac¬ 
curate  source  of  velocity  data  for  the  GPS/IMS  velocity  monitor,  while  the  flight  con¬ 
trol  gyros  provide  a  source  for  the  attitude  estimator  to  calculate  a  short-term  esti¬ 
mate  of  aircraft  attitude.  No  additional  source  of  forward-looking  radar  data  Is  avail¬ 
able  for  comparing  with  the  TFR  data,  but  data  from  CARA  is  available  to  provide  verti¬ 
cal  plane  monitoring  of  nearness  to  terrain  peaks  during  TFR-controIIed  flight  with  the 
low  TP  monitor  for  detection  of  fly-low  angle  error  effects.  If  the  CARA  altitude  be¬ 
comes  less  than  75  percent  of  the  TF  set  clearance,  an  automatic  fly-up  maneuver  is 
Initiated  based  either  on  a  similar  low-altitude  check  circuit  in  the  LANTZRN  navigation 
pod  or  by  the  independent  DFLCS  low  TF  monitor. 


Tliblm  1  Drtfl  mnd  Bias  Errors  Swim  Fsaturss 


FEATURE 

mUURE  DETECTION 

LOCATION 

ATTrrUDC  EariMATOR 

INS  ATTITUDE 

DFLCS 

QPsnNs  vcLocmr 
MONnOR 

INS  INERTIAL  VELOCITY 

DFLCS 

LOW  TF  MONITOR 

TFR  FLY-LOW  ERROR 

DFLCS 

Subsystem  Processor  Self-Test  Coverage.  Table  2  is  a  summary  of  the  SWIM  features 
covering  subsystem  processor  hazardous  malfunctions.  Additional  coverage  is  provided 
for  undetected  failures  in  the  CARA  signal  data  converter  (SDC)  via  the  CARA  SDC  monitor 
since  the  SDC  does  not  have  significant  coverage.  The  CARA  receiver/transmitter  cover¬ 
age  is  significant  because  of  automatic  self-test  and  out-of-track  detection  circuitry, 
both  of  which  are  monitored  by  DFLCS  SWIM  features.  Failures  in  the  CARA  SDC  are  moni¬ 
tored  by  comparing  the  analog  CARA  data  presented  to  the  SDC  with  the  digitized  radar 
data  the  SDC  provides  to  the  TF  system.  Relatively  straightforward  monitors  could  not 
be  implemented  for  the  TFR  processors^  instead,  a  cyclic  redundancy  test  (CRT)  was  used 
to  implement  a  cyclic  TF  command  and  obstacle  warn  algorithm  problem.  The  cyclic  prob¬ 
lems  Involve  comparing  computational  test  cases  performed  in  the  TFR  processors  with 
predetermined  results  for  those  test  cases. 
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FAIUJRE  DETECTION 

LOCATION 

CARA  aOC  MONnOR 

SDC 

DPLCS 

CARA  SELFTEST 
MONTIDR 

ACrmiOE  ABOVE 
GROUND  LEVEL 

DFLCS 

OUFOFTRACK 

MONITOR 

AinrUDB  ABOVE 
GROUND  LEVEL 

OFLCS 

CYCLIC  TF  COMMAND 
PROBLEM 

COMMAND  PROCESSOR 

DFLCS/NAV  POD 

CYCUC  OBSTACLE 
WARN  TEST 

OBSTACLE  WARN 
PROCESSOR 

DPLCSMAV  POD 

System  Commanloatlon  Paths,  Table  3  contains  the  SWIM  features  implemented  to  pre¬ 
vent  undetected  loss  of  communication  paths.  Undetected  failure  modes  exist  in  the  1553 
data  bus  remote  terminals  (RT)  of  various  TF  subsystems.  Several  methods  are  used  to 
monitor  these  fallurest  for  the  CARA  RT»  the  CARA  SDC  monitor  provides  sufficient 
coverage  of  TF  failures}  wraparound  checks  of  communication  paths  with  alternating  data 
values  are  used  to  monitor  the  other  RT  failure  modes.  Redundant  TF  data  good  and  data 
Integrity  discretes  provided  by  subsystem  processors  are  also  monitored  to  identify  In¬ 
valid  TF  operation.  These  discretes  are  external  to  the  1553  communication  bus.  An 
Auto  TF  select  monitor  verifies  Auto  TF  engagement  to  prevent  the  pilot  from  relinquish¬ 
ing  vertical  clearance  control  to  a  disengaged  Auto  TF  system. 


Table  3  Communication  Path  Loss  Swim  Features 


FEATURE 

FAIUJRE  DETECTION 

LOCATION 

MUX  WRAPAROUND 

TF  INFO  TRANSMISSION 

DFLCS/NAV  POD 

REDUNDANT  TF  GOOD 

NAV  POO  TF  STATUS  LOSS 

DFLCS 

DATA  INTEGRITY 

TF  SUBSYSTEM  STATUS  LOSS 

DFLCS 

AUTO  TF  SELECT 
MONITOR 

AUTO  TF  DISENGAGEMENT 

DFLCS 

Predicted  Mishap  Rate  Improvement 

In  Figure  7,  the  percent  reduction  in  mishap  rate  Is  depicted  for  various  F-16  TF 
configurations;  single-thread,  redundant  (dual  CARA  and  INS),  and  single-thread  with 
SHIM.  As  can  be  seen  from  Figure  7,  redundancy  affords  maximum  safety  benefit  at  17 
percent  reduction  In  predicted  mishap  rate.  However,  the  addition  of  SWIM  to  the 
single-thread  configuration  is  seen  to  achieve  14  percent  predicted  mishap  rate  reduc¬ 
tion  at  far  leas  cost  and  Installation  impact  than  the  redundant  configuration.  It 
should  be  noted  that  the  mishap  rate  Improvement  in  the  low-altitude,  high-speed  regime 
Is  limited  by  factors  such  as  engine  malfunction  and  bird  strike  —  as  depicted  by  the 
fact  that  only  25  percent  improvement  is  achievable  with  a  perfect  TF  system. 
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Cost  Effectiveness 


As  previously  Indicated,  the  cost  to  add  SWIM  to  the  single>thread  baseline  F>16  TF 
system  was  $2  million.  This  cost  and  the  additional  cost  over  the  single«thread  base> 
line  of  a  redundant  INS  and  CARA  TF  system  and  of  a  perfect  TF  system  are  compared  in 
Figure  8.  The  costs  depicted  in  Figure  8  are  all  based  on  incorporation  into  350 
LANTIRN-equlpped  F-l6  aircraft.  As  shown  In  Figure  8,  a  cost  of  approximately  $500  mll> 
lion  is  required  to  achieve  the  perfect  TF  system,  in  terms  of  hazardous  malfunction  de¬ 
tection,  via  triplex  subsystems,  including  the  TF  sensor.  Of  more  interest  Is  the  cost 
of  more  traditional  TF  system  redundancy  involving  at  least  dual  subsystems  except  for 
the  single  TF  sensor.  The  traditional  redundant  TF  system  costs  approximately  $100  mil¬ 
lion  to  achieve  the  same  order  of  aircraft  savings  as  single-thread  with  SWIM  at  $2  mil¬ 
lion.  From  the  Figure  7  mishap  rate  reduction  data  and  the  Figure  8  cost  data,  a  cost- 
effectiveness  comparison  can  be  made  for  the  alternate  P-1S  TF  systems  relative  to  the 
single-thread  TF  baseline.  Figure  9  is  a  graphic  Illustration  of  the  cost-effectiveness 
comparisons  from  which  it  can  be  seen  that  —  in  terms  of  safety  improvement  ~  the  appli¬ 
cation  of  SWIM  to  the  single-thread  configuration  resulted  in  140  times  as  cost-effec¬ 
tive  a  TF  system  as  a  perfect  system  and  47  times  (140/3)  as  cost-effective  a  system  as 
the  redundant  INS  and  CARA  system. 
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Figure  9  Altemste  F-16  TF  System  Cost  Effectiveness 

Monitor  Implementation 

It  is  necessary  to  Implement  the  monitors  in  a  reliable  fault-tolerant  computation¬ 
al  system  to  ensure  reliability  of  the  SWIM  monitor  circuitry  and  also  prevent  erroneous 
failure  declarations.  The  DFLCC  is  an  ideal  home  for  the  SWIM  monitors,  because  the 
fault-tolerant  architecture  for  such  processing  already  existed  to  handle  the  failure 
management  needs  of  the  flight  control  system.  The  monitors  were  implemented  as  an  ad¬ 
ditional  software  function  in  each  redundant  branch  of  the  quad  DFLCC.  The  impact  to 
the  Flight  Control  Computer  Operational  Flight  Program  and  throughput  is  small,  as  only 
the  SWIM  monitor  logic  was  required  to  be  added.  The  existing  softwai e  to  implement 
signal  and  failure  management  was  utilized  to  ensure  the  SWIM  monitors  were  not  affected 
by  failures  In  the  flight  control  computer. 

In  addition  to  the  SWIM  monitors  already  discussed,  additional  monitors  were  imple¬ 
mented  in  flight  control  software  to  assess  the  health  of  the  various  TF  subsystem  com¬ 
ponents.  The  status  of  each  subsystem  BIT  is  reported  to  the  DFLCC,  and  monitors  are 
implemented  to  determine  the  health  of  each  subsystem  based  on  the  subsystem  BIT  status. 
The  DFLCS  also  checks  data  passed  between  the  TF  subsystems  to  evaluate  subsystem 
health.  The  checks  verify  that  the  data  values  are  within  expected  bounds. 


Monitor  Action 

Whenever  a  failure  in  the  TF  system  is  detected,  the  method  used  to  correct  the 
failure  is  to  terminate  TF  and  provide  an  automatic  roll  to  wlngs-level  fly-up.  The  In- 
cremental-g  level  for  a  particular  fly-up  depends  on  the  system  or  condition  that  de¬ 
tected  the  failure.  Table  U  lists  the  incremental-g  levels  and  the  system  initiating 
the  fly-up  commands. 

The  subsystem  failures  are  detected  by  self-test  or  by  a  SWIM  monitor.  The  Verti¬ 
cal  Clearance  Warning  (VCW)  is  based  on  CARA  altitude  and  is  caused  by  the  airplane 
penetrating  75  percent  of  the  SCP.  The  Obstacle  Warn  (OW)  is  based  on  the  TFR  and  is 
generated  when  some  object  not  previously  sensed  by  the  TFR  is  detected  within  an  ap¬ 
proximately  3-g  template  in  front  of  the  airplane. 


IWt  4  Automtic  Roll  to  WIngo-Lovol  Fly-Up  Q  Levels 
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System  Validation 


An  extensive  failure  modes  evaluation  testing  (FMET)  was  conducted,  in  addition  to 
the  standard  validation  tests,  to  establish  confidence  in  SWIM  monitor  operation  in  the 
face  of  actual  or  simulated  hardware  failures  and  to  ensure  that  proper  pilot  displays 
and  handling  qualities  are  maintained  during  failure  identification  and  recovery.  FMET 
was  conducted  in  real  tine  in  a  handling  qualities  simulator  with  a  pilot  In  the  loop. 
Critical  TF  system  processor  hardware,  such  as  the  avionics  suite,  the  flight  control 
computer,  and  the  TFR  processors,  were  included  to  ensure  correct  timing  and  processing 
of  the  TF  functions.  In  addition,  all  of  the  selected  SWIM  features  are  being  evaluated 
In  F-16/LANTIRN  TF  flight  tests,  which  began  in  January  of  1988  and  are  scheduled  to 
continue  until  late  1968. 


SWIM  Study  Conclusions 

For  optimum  failure  detection  in  any  system,  redundancy  is  the  best  Implementation 
method,  as  redundancy  provides  a  means  to  detect  failures  by  comparison.  However,  as 
previously  discussed,  redundancy  is  not  present  in  many  of  the  F>16  TF  subsystem  sensors 
or  processors  due  to  space  limitations. 

The  SWIM  method  of  failure  detection  was  developed  to  enhance  hazardous  failure  de¬ 
tection  in  a  single-thread  system.  This  method  was  not  intended  to  replace  redundancy. 
However,  System-Wide  Integrity  Management  did  accomplish  its  intended  purpose  —  a  signi¬ 
ficant  decrease  In  predicted  mishaps  from  otherwise  undetected  failures  in  the  TF  sys¬ 
tem.  In  addition,  SWIM  achieved  almost  as  much  predicted  mishap  rate  improvement  as  the 
redundant  system  at  far  less  cost  and  installation  impact  for  a  phenomenal  cost-effec¬ 
tiveness  advantage  over  traditional  redundancy. 


DISCUSSION 


J.Bart,  US 

What  was  the  haise  Alarm  Kate  (Improper  Identification  of  Failure  Condition)  using  the  SWIM  approach? 

Author's  Reply 

The  implementation  of  either  a  digital  or  software  implemented  monitor  could  have  an  uiitially  unacceptable  false 
alarm  rate  due  to  too  low  a  value  of  persistence  counts  or  too  tight  trip  levels.  However,  these  values  are  generally 
corrected  during  system  simulation  and  flight  test  and  achieve  an  acceptable  false  alarm  rate.  However,  software 
monitors  utilizing  existing  hardware  have  an  inherent  advantage  over  traditional  hardware  monitors,  in  that  they  do  not 
suffer  from  the  additional  false  alarm  rate  associated  with  hardware  self  test  and  component  drift  errors.  For  SWIM,  the 
implementation  of  the  monitors  in  software  has  thus  resulted  in  a  quantitatively  lower  false  alarm  rate  than  systems 
implemented  with  traditional  redundant  hardware  techniques. 
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CAN  Ada  (MiL-STD-lSlSA)  FLY  MISSILES? 

by 

CulW.HaU 
Naval  Weapons  Center 
Missile  Software  Branch 
China  Lake,  California  USA  93555-6001 


SUMMARY 


A  small  group  of  software  engines  at  the  Naval  Weapons  Center  explored  the  transition  of  the  M]LrSTD-1815A  (Ada)  language 
and  associa^  technology  into  the  Navy  missile  domain  beginning  in  October  1984.  The  project  was  funded  by  Independent 
Exploratory  Development  (lED)  funds.  It  had  a  principal  objective  to  develop  operational  software  for  a  typical  navy  missile  in  Ada, 
while  examining  the  issues  associated  with  deployment  of  the  Depanment  of  Defense  (DoD)  standard  language  in  a  leal-tiine  missile 
envirofimenL 

The  project  lasted  3  years  and  was  finished  in  Septento^  1987  with  the  Ada  software  nmning  in  a  breadboard  version  of  dw  missile 
guidance  computer.  The  final  version  of  die  software  had  almost  all  the  missile  functioDs  included  with  the  exception  of  the  safety 
module.  Safety  deals  with  the  range  requiiemmts  during  testing  and  this  data  were  not  available.  The  computer  and  software  are  being 
moved  to  the  Hardware-ln-the-Loop  (HWIL)  facility  where  diey  will  be  integrated  with  various  misstle  hardware  and  a  six-degree-of- 
freedom  simulackMi.  Current  plans  are  to  seek  funding  to  fly  a  test  missile  at  the  Naval  Weapons  Center  range  with  a  modified  version 
of  the  lED  Ada  code. 


BACKGROUND 

Ada  is  a  computer  language,  the  product  of  a  12-year  development  program  designed  to  provide  a  standardixed  and  effective  higher- 
order  programming  language  for  DoD  use.  Its  features  and  constructs  were  designed  to  supply  a  tool  to  control  software  costs  for 
tactical  embedded  computer  systems  in  military  weapon  systems.  In  July  1983,  the  DoD  Deputy  Director  for  Research  and  Engineering 
issued  a  policy  directive  that  read  in  part.  "Effective  1  January  1984,  for  programs  entering  Advanced  Development,  and  1  July  1984, 
for  programs  entering  Full-Scale  Engineering  Development  (FSED),  Ada  shall  be  the  programming  language." 

The  North  Atlantic  Treaty  Organization  (NATO)  committed  to  use  Ada  for  the  implementadon  of  its  information  systems  that 
support  the  exercise  of  comm^,  control,  and  cemununication  within  the  Alliance.  On  25  January  1985,  the  NATO  Defense  Planning 
Committee  approved  NATO's  Ada  Policy,  effective  in  1986.  The  Policy  made  Ada  the  single  higher-mder  language  for  all  NATO 
oommand  and  control  information  system  projects  not  invt^ng  France.  NATO  permits  the  use  of  another  language  for  such  systems  if 
a  waiver  is  requested  and  granted. 

Ada  became  an  international  standard  on  12  March  1987  when  the  Ontral  Secretariat  of  the  Internationa]  Standards  Organization 
(ISO)  announced  unanimcHis  af^iroval  of  the  Draft  International  Standard  (DIS)  8652 — Programming  Language  Ada.  The  standard  is 
known  as  ISO/8652-1987  Programming  Language  Ada  and  is  an  endexsement  of  the  American  and  French  Ada  standards  (ANS/MIL- 
STD-1815A  and  NF  Z  65-700,  respectively). 

In  March  and  April  of  1987,  (he  United  States  Deputy  Secretary  of  Defense  (the  Honorable  William  H.  Taft.  IV)  gave  ftnther 
support  10  the  Ada  software  initiative  by  signing  two  new  directives  (3405.1  and  3405.2).  Directive  3405.1,  the  "Computer 
Programning  Language  Policy."  states  The  A^  programming  language  shall  be  single,  common,  computer  programming  language  ftv 
Defense  computer  resources  used  in  inteUigence  systrans,  for  the  command  and  control  of  military  forces,  or  as  an  integral  pan  of  a 
w^pon  system...Ada  shall  be  used  few  all  other  applications,  except  when  the  use  of  another  approved  higher  order  language  is  mott 
cost  effective  over  the  application's  life-cycle,  in  keeping  widi  the  long-range  goal  of  establishing  Ada  as  the  primary  IDoD  higher  ord» 
language." 

Directive  3405  the  "Use  of  Ada  in  Weapon  System,"  states  that  Ada  shall  be  the  single,  common,  higher-order  language  used  for 
all  new  weapon  systems  during  all  phases  of  the  life  cycle  and  to  major  software  upgrades  of  existing  weapon  systems.  The  directive 
further  requires  the  use  of  validated  Ada  conopilers,  of  software  engineering  principles  described  in  DOD'STD-2167  and 
DOD-HDBK-281,  and  of  Ada  as  a  program  design  language  <PDL)  to  design  software. 


INTRODUCTION 

Ihis  cxpioraiocy  development  program  attempted  to  analyze  the  major  issues  associated  with  tnsening  Ada  in  a  missile.  In  order  to 
achieve  the  goals  of  this  project,  it  was  deemed  necessary  to  avoid  the  popular  trend  of  translating  a  working  program  into  Ada. 
Avoiding  translation  of  an  existing  program  meant  the  important  issues  involved  in  utilizing  Ada  in  all  the  life  cy^  i^iases  could  be 
studied.  The  power  of  Ada  is  sometimes  lost  when  translating  fiom  a  different  language  into  Ada  because  the  programmer  is  not 
anxious  to  rebuild  a  working  design.  Another  danger  is  the  tendency  to  propim  in  Ada  as  one  does  in  other  languages.  A  good 
fortran  design  may  not  be  a  good  Ada  design.  In  fact,  there  is  evidence  to  the  contrary. 
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Therefore,  a  missile  program  was  selected  to  wh^h  the  missile  had  not  yet  been  flown  and  fc»'  which  little  or  no  code  had  been 
written.  The  qjecifications  for  the  missile,  the  wei^x}n's  tacticai  computer  design,  and  the  compu^r  program  performance  specification 
(Cf^)  were  available  and  could  be  used  to  develop  the  (^)ereiIonal  flight  software  (OFS)  in  Ada.  A  breadboard  version  of  the 
guidance  computer  was  built  for  the  HWIL  facility  lirom  the  conncior's  design  and  could  be  used  to  test  the  OFS  once  completed. 

During  the  developinent.  which  spanned  3  yean,  controls  had  to  be  established  to  avoid  losing  sight  of  the  objectives.  These 
controls  were  specified  in  a  software  developfoent  plan  (SDP).  Frequent  peer  group  reviews  were  held.  Also  each  contributor  had  to 
maintain  a  programmer/anaiyst  notd>ook,  which  was  reviewed  periodically  by  the  principal  investigator  of  the  project,  instead  of 
develt^Mg  a  software  quality  evaiuadon  plan,  the  {Hocess  was  included  in  the  SDP. 

In  the  SDP,  the  major  issues  were  listed  in  order  to  maintain  focus  on  what  the  project's  objectives  were.  These  issues  changed 
through  the  course  of  the  project  as  circumstances  and  funding  levels  changed  The  following  list  provides  the  final  state  of  those  issues 
after  several  iterations  had  oocuned  during  the  course  of  the  project: 

1 .  How  suitable  are  the  Ada  features  for  a  stringent  real-tiine  problem  with  limited  throughput  and  memory  such  as  missiles  have? 

2 .  What  are  the  theoretical  aivl  pragmatic  issues  one  must  solve  or  undeistaiai  tt>  implement  Ada  in  an  embedded  tactical  weapon 
system? 

3 .  What  issues  are  associated  with  the  compiler,  runtime  system  (RTS),  tools,  and  compiler  validation? 

4 .  Can  usefiil  st^tware  metrics  be  automated  that  measure  Ada's  effectiveness  and  the  prt^rammer’s  final  Ada  product? 

5.  Can  Ada  benchmarks  or  perfocmance  tests  help  quantify  a  validated  Ada  compiler’s  time  and  memc^  expansion  factors  over 
assembly  language? 

6.  Does  Ada  improve  productivity,  maintainability,  and  reliability  weapon  software  while  reducing  cost  and  development  time? 

As  the  project  progressed,  the  decision  to  change  the  guidance  computer  microprocessor  from  a  Zilog  Z8002  to  a 
Motorola  MC6$020  gave  the  lED  task  a  new  dimension  in  its  insertion  effort.  The  theory  of  Ada's  transportability  or  machine 
independence  came  into  the  pragntatic  wcvld  of  a  new  compiler,  a  new  development  system,  cost  overrun,  schedule  slippage,  a  new 
emulator,  and  procurement  cycle  delays.  The  parocular  Ada  compiler  purchased  required  a  Digital  Equipment  Corporation  MicroVax  11 
computer.  The  first  emulator  purchased  never  funetk^ted  as  advertised  and  had  lo  be  abandoned  afta  6  months  of  frusu^don. 

Nevertheless,  the  project  concluded  on  schedule  and  under  cost  with  the  OFS  coded  in  Ada  and  running  open-looped  in  the  missile 
guidance  computer.  In  September  1997,  there  were  about  222,000  bytes  of  compiled  Ada  object  code  and  approximately  11,000  lines 
of  Ada  statements  in  the  missile  program.  Whereas  some  issues  remain  under  investigation,  others  were  examined  and  concluded. 

DESIGN  METHODOLOGY 

Several  methods  were  studied  before  selecting  one  with  which  to  design  the  lED  software.  The  popular  method  being  touted  for 
Ada  programming  was  the  object-oriented  design  (OOD)  methodology  ( 1  ].  Structured  analysis/structured  design  (SA/SD)  [2]  was  a 
popular  design  method  of  the  1970s.  The  object  flow  method  used  object  flow  graphs  instead  of  data  flow  diagrams  (DFDs).  Other 
less  used  techniques  were  the  State  Machine  approach  and  Petri  Nets.  Traditional  mathematical  flowcharts  are  g^  for  illustrating  the 
algorithmic  flow  of  the  program  but  tend  to  be  written  only  after  a  program  is  working. 

Because  the  computer  program  performance  specification  was  functionally  decomposed,  it  seemed  at  the  time  reasonable  to  assume 
that  SA/SD  methodology  would  map  better  onto  the  missile  domain  selected.  The  priority  and  sequencing  of  missile  tasks  were  very 
rigid  in  most  modes.  Also,  the  computer  only  had  a  single  microprocessor,  which  implied  linear  processing,  and  preliminary 
investigation  had  flagged  the  Ada  tasking  rendezvous  as  a  concern.  This  choice  of  SA/SD  caused  some  problems  during  the  project. 
DFDs  and  structure  chans  do  not  handle  interrupts  nor  illustrate  control  very  well.  The  data  dictionary  is  an  excellent  resource,  Init  it 
lacks  specific  ififotmation  required  to  type  the  daa  objects. 

Because  initial  discussions  with  compiler  vendors  established  large  rendezvous  times  exceeding  1  millisecond  (some  were  as  high 
as  10  milliseconds),  plans  were  made  to  build  a  generic  executive  (GENE)  to  operate  cyclically  on  a  time-slice  dieory.  The  intent  was 
to  use  as  much  the  runtime  system  as  possible  and  allow  GENE  to  handle  the  "hot”  spots  like  tasking  and  interrupts.  This  succeeded 
quite  well.  In  May  1987,  the  Software  Engineering  Institute  at  Carnegie-Meilon  University  published  a  technical  report  (3)  n4uch  stated 
on  page  43,  "Most  of  Ada's  benefits  can  be  achieved  for  real-time  systems  even  if  Ada’s  tasking  features  are  not  used...If  Ada  tasks  are 
not  used,...die  need  to  use  art  existing  real-time  executive  or  wrire  a  special-purpose  executive  must  be  included  as  part  of  any  project 
plan." 

The  concept  for  the  lED  executive  was  quite  simple  in  structure  as  illustrated  in  Figure  I .  The  executive  isolates  the  application 
tasks  from  both  the  runtime  system  and  the  computer  with  its  interrupts  and  InputA)utput  operations.  The  ideal  situation,  hovrever,  is 
when  the  runtime  system  can  handle  the  missile  ^vironment  efficiently  enough  to  not  require  a  complementary  cyclic  executive  like 
GENE.  The  reason  its  transportability.  If  one  is  not  careful,  the  cyclic  executive  becomes  so  specializi^  that  it  cannot  be  used  on  other 
projects. 
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nOURE  1.  GENE. 


To  avoid  this  problem,  GENE  was  broken  into  two  components;  viz.,  generic  and  primitive.  The  generic  component  was  designed 
to  work  with  other  missile  projects.  GENE  accomplished  this  and  is  in  another  missile  program  operating  efficiently  and  correctly.  The 
generic  component  is  reusable,  however,  if  both  applications  use  die  same  language.  The  primitive  component  is  machine-dependent 
and  will  not  transpcnn.  It  is  specifically  tailored  to  optimi»  the  communication  between  the  machine  and  the  generic  component.  Ln 
most  instances,  this  means  programming  in  assembly  language.  For  the  lED  code,  GENE  was  programmed  in  Ada  and  its  primitives  in 
assembly  language. 

GENE/RTS  was  at  the  heart  of  (he  lEO  software.  The  basic  top-level  structure  was  the  introduction  of  an  application  package. 
GENE/RTS  could  theoretically  invoke  di^'erent  application  packages  for  different  missiles.  Because  external  missile  sensors  had  direct 
memory  access,  a  global  data  package  was  created.  Howe>^,  the  t^ginal  intent  was  to  place  only  type  declarations  and  constants  in  a 
global  package  available  to  all  the  application  tasks.  Each  major  task  was  designed  to  use  parameter  calls  with  the  Ada  in,  in  out,  out 
mechanism  with  its  subordinate  procedures.  For  clarity,  the  major  tasks  had  to  include  Input/Output  lists  in  their  respective  "module 
header."  In  this  way,  each  task  could  be  invoked  when  an  interrupt  occurred,  and  if  data  were  ready  in  the  global  package,  it  would  be 
autonomous  from  the  other  missile  tasks.  When  data  was  not  ready,  GENE  kept  the  task  asleep  until  the  interrupt  occurred. 

The  last  design  technique  applied  was  the  use  of  Ada  as  a  PDL.  After  attending  several  demonstrations  of  Ada  superset  PDL  tools 
like  BYRON  built  by  Rational  Inc ,  a  decision  was  made  to  use  Ada  only.  The  fundamental  reason  for  rejecting  an  Ada  superset  was 
cost.  The  lED  project  was  on  an  austere  budget  and  couldn’t  afford  the  expense.  Therefore,  developers  of  the  various  Ada  tasks  were 
directed  to  use  Ada  as  a  programming  design  language  until  their  tc^-level  design  was  completed  and  reviewed.  Each  design  was 
reviewed  in  a  structured  walkthrough  as  outlined  in  reference  (4). 

One  further  note  concerning  the  lED  software  design  proce.ss.  The  belief  that  one  particular  design  methodology  will  solve  all  the 
design  issues  is  not  in  harmony  with  practical  expenence.  A  project  should  use  a  disciplined  approach  to  the  development  of  software 
and  build  early  prototypes  to  test  these  preliminary  designs.  Most  successful  software  engineers  have  been  doing  this  for  years  even 
though  DoD  Directive  5000.29  essentially  forbids  it.  The  lED  team  discovered  that  the  missile  CPPS  was  incomplete  and  that  the 
requirements  were  constantly  in  motion.  The  navigation  prototype  helped  establish  the  missing  specifications  to  a  large  degree. 
Figure  2  shows  the  1X)D'STD-2167  waterfall,  the  defense  software  procurement  cycle,  and  the  operational  software  and  shows  how 
the  prototype  software  relates  to  these  three  life  cycle  categories. 


COMPILER 

The  project  began  with  a  nonvalidated  Ada  compiler  fev  the  ZS002.  There  was  no  validated  compiler  at  the  time.  Tlte  first  lesson 
learned  was  NEVER  use  a  nonvalidated  compiler.  One  frequently  did  not  know  when  errors  rccuired  whether  they  were  actual  errors 
or  the  compiler's  problem.  Also,  all  the  workarounds  are  time-ermsuming  and  demoralizing.  The  commercial  company  building  the 
compiler  promised  imminent  validation  for  2  years.  Today’s  market  of  validated  Ada  compilers  is  large  enough  that  this  lesson 
shouldn't  be  relearned  by  anyone. 

When  the  decision  was  made  to  replace  the  Zilog  Z8002  microprocessor  in  the  guidance  computer  with  a  Motorola  MC68020  and 
MC68881,  a  search  began  for  another  Ada  compiler.  This  effort  spawned  a  task  to  develop  some  formal  method  for  evaluating  Ada 
compilers  built  for  a  desired  processor.  This  effort  was  documented  in  reference  [S],  Kernel  to  the  task  was  the  generation  or 
inheritance  of  18,000  lines  of  Ada  benchmarks.  These  benchmarks  were  used  more  like  performance  tests.  The  Ada  Joint  Program 
Office  (AJPO)  in  the  Office  of  the  Secretary  of  Defense  (OSD),  responding  r>  the  fact  that  validation  does  not  quantify  performance,  has 
a  contract  in  place  to  procure  an  Ada  Compiler  Evaluation  Ca{»bility.  This  contract  is  administered  by  Wrigbt-Patterson  Air  Force  Base 
and  performed  by  the  Boeing  Company. 
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The  productivity  figures  for  this  enbrt  showed  a  definiie  increase  of  between  two  and  five  times  over  comparable  assembly 
language  projects.  The  variance  in  these  figures  is  due  to  the  fact  that  the  project  did  not  have  an  assembly  language  version  of  the 
sr^waic  for  annparison.  Industry  standards  range  from  a  bidding  data  base  of  about  five  documented  validated  verified  lines  of  code 
(DVVL)  to  a  cottage  industry  figure  of  around  12  DVVL.  Comparable  cost  factors  showed  a  decrease  in  ^st  of  between  IS  and 
10  times. 

In  analyzing  these  two  results^  there  are  perh^  factors  that  influenced  those  nundieis  external  to  die  Ada  language  itself.  The 
project  was  a  research  study  and  was  staffed  with  higb<aliber  people.  A  pre^ram  performance  specification  was  available  at  the 
beginning  of  the  project.  Although  it  was  not  complete  or  100%  accurate,  it  was  tremendously  useful.  This  is  unlike  many  projects 
where  the  qiecificatioos  and  requirements  evolve  during  development  Also,  the  documentation  requiremotts  were  not  the  entire 
D(X>-STD-2167  documentadon  suite.  Documentadon  coats  l^ve  bees  known  to  tun  as  high  as  30%  to  S0%  of  nuliuuy  software. 

Although  one  might  ^leculate  on  many  causes  and  effects,  the  fact  remains  that  the  people  involved  in  the  demonstradon  found 
themselves  producing  wenking  code  quicker  than  previousiy  experienced.  Most  participants  also  discovered  that  in  the  course  of 
3  years,  it  was  not  an  overwhelming  t^  to  understand  another  co-worker's  code.  This  has  to  be  attributed  to  the  language's  natural 
language  reserve  words  and  a  concencraied  effort  lo  use  meaningful  labels  for  data  objects  as  well  as  regular  peer  group  reviews.  Thus 
the  maintainability  issue,  while  not  answered  endiely  in  this  project,  cenainly  raised  the  expectadon  level  that  maintainable  code  could  be 
produced  using  tte  Ada  language.  It  is  felt  that  the  tools  are  available  for  producing  maintainable  code  if  correctly  applied.  Tliese 
results  appear  in  harmony  with  those  obtained  in  the  F-IS  Eagle  Dual-Control  Augroentadon  System  [8]  where  the  microprocessors 
were  programmed  in  Ada. 

Some  useful  heuristics  about  programming  in  Ada  were  gleaned  from  the  demonstradon.  These  are  listed  below  without 
jusdficedon  or  explanadtm: 

1.  Write  simple  code.  Complexityoccursnaturally  in  a  military  weapon. 

2.  Program  first  in  Ada.  regressing  into  another  language  only  when  necessary. 

3.  Design  with  maintenance  in  mind. 

4.  Use  a  comment  block  at  the  beginning  of  each  pro^am  unit  (9). 

5.  Create  no  Data  label  over  one  line  in  length. 

6.  Use  "with"  alone  rather  than  "with"  and  "use’*. 

7 .  When  Ada  code  runs  too  slow,  isolate  Inefficient  Ada  cwismicts  and  replace  them  if  possible.  Revert  to  another  language  as  a 
last  reson. 

8 .  Do  not  expect  Ada  to  be  a  panacea  but  a  step  in  the  right  direction  at  least  undl  the  technology  base  matures. 

9.  Use  the  Language  Reference  Manual  but  supplement  it  with  good  books  on  Ada. 

\  0.  Package  the  constants  and  data  types. 

The  last  result  was  the  software  metrics  developed.  To  measure  such  qualities  as  readability,  maintainability,  and  reliability  of  Ada 
code,  one  requires  an  automadc  tool.  The  Naval  Postgraduate  School  in  Monterey,  California  and  the  Naval  Weapons  Center  entered 
into  an  agreement  to  develop  a  software  metric  program  using  graduate  students  working  on  master  degrees  in  computer  science.  The 
first  two  students,  Cmdr.  Jeffrey  Neider  and  Lt.  Karl  Fairbanks,  completed  the  foundation  program  which  performed  static  metrics  on 
Ada  source  code  [10].  A  system  has  been  developed  that  implements  Halstead's  length  metric,  Henry  and  Kafura’s  information  flow, 
number  of  comment  lines,  readability  assessment  of  the  comments,  and  depth  of  the  nesting  level.  This  metric  tool  will  continue  to 
grow  as  more  students  contribute  to  the  product 

It  was  rewarding  to  learn  upon  applying  tfte  static  metrics  to  the  lED  code  that  the  analysis  indicated  that  the  code  was  well  above 
the  acceptable  levels.  That  the  two  groups  wmked  fairly  much  independently  of  one  anoih»  ttnds  to  lend  credence  to  the  results.  The 
addidtm  of  more  metrics  into  the  base  program  and  perhaps  expanding  tt>  include  some  dynamic  metrics  are  future  plans. 

In  kr  clusicm,  the  answer  to  the  rhetorical  question  posed  in  the  tide  of  this  paper  appears  to  be  a  qualified  yes. 
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Abstract 

The  protocol  for  synchronous  approximate  agreement  presented  by  Dolev  al.{7j  exhibits  the  undesirable  property  that  a 
faulty  processor,  by  the  dissemination  of  a  value  arbitrarily  far  removed  from  the  values  held  by  good  processors,  may  delay 
the  termination  of  the  protocol  by  an  arbitrary  amount  of  time.  Such  behavior  is  clearly  undesirable  in  a  fault  tolerant 
dynamic  system  subject  to  hard  real-time  constraints.  This  work  presents  a  mechanism  by  which  editing  data  suspected  of 
being  from  Byzantine-failed  processors  can  lead  to  quicker,  predictable,  convergence  to  an  agreement  value.  Under  specific 
assumptions  about  the  nature  of  values  transmitted  by  failed  processors  relative  to  those  transmitted  by  good  processors, 
we  present  Monte  Carlo  simulations  whose  quantitative  results  illustrate  the  trade-off  between  accelerated  convergence  and 
the  accuracy  of  the  value  agreed  upon. 


1  Introduction 

One  approach  to  the  construction  of  a  fault  tolerant  computing  system  is  through  redundancy  in  the  system  hardware  and/or 
software.  Several  alternative  architectures  for  a  redundant  avionics  subsystem,  resilient  to  some  number  of  hardware  and 
software  failures,  are  shown  in  Figure  1.  In  each  alternative,  four  processors,  through  P,,  execute  individual  »-eplicates 
of  a  particular  software  function.  That  function  causes  each  processor  to  map  digital  sensor  input  into  an  output  which  is 
intended  to  drive  some  physical  actuator  or  display.  In  alternatives  (a)  and  (d),  each  processor  has  access  to  its  own  sensor. 
In  alternatives  (b)  and  (c),  the  processors  share  access  to  a  single,  presumably  very  reliable,  sensor.  The  output  of  each 


(c)AgreeinefU  on  Single  Sensor  (d)  All  Sensor  Values  Disseminated 


Figure  1:  A  Redundant  Subsystem 

processor  is  a  vote  in  an  election  to  determine  the  sole  output  of  the  (sub)syst€m.  The  redundancy  in  this  subsystem  is 
intended  to  tolerate  the  fmlure  of  any  single  processor  or  frmetion  (software).  In  the  case  of  alternatives  (a)  and  (d),  the 
potential  for  realience  to  sensor  failure  also  exists. 

The  assumption  that  the  function  replicates  ful  independently  (an  important  assumption  for  the  efficacy  of  N- 
version  programming(3,5])  has  been  empirically  shown  to  be  invalid  in  practicc[U].  Also,  analytical  work  suggests  that  the 
possibility  of  coincident  errors  in  the  function  replicates  may  require  a  higher  degree  of  redundancy  than  would  be  intuitively 
expected  and  that,  in  some  situations,  the  reliability  of  the  N-veraon  system  would  be  less  than  that  of  a  1-version  systemfS] . 

‘Supported  io  part  by  the  Army  Avionics  Research  k  Development  AcUvity  through  NASA  Grant  NAG-1.787. 
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These  problems,  however,  arc  irrelevant  to  the  struclure  of  a  modularly  redundant  system.  Their  impact  is  felt  in  the  degree 
of  fault  resilience,  and  it  has  been  argued  that  careful  design  of  the  rejrficates  and  their  integration  into  the  system  czm  lead 
to  an  acceptable  level  of  resilienceflj. 

A  key  assumption  in  the  preceding  argument  that  redundancy  provides  resilience  is  that  of  input  congruence.  If  the 
software  functions  are  truly  replicates  of  one  another,  then  they  are  intended  to  compute  the  same  output  if  they  are 
preiented  with  the  same  set  of  inputs.  In  the  system  of  Figure  1,  several  intuitive  alternatives  for  providing  function  input 
are  available: 

(a)  Each  function  uses  the  data  presented  by  its  attached  sensor. 

(b)  single  sensor  provides  input  for  the  system.  That  sensor's  output  is  cross-strapped  to  the  input  of  all  function 
replicates. 

(c)  A  single  sensor  value  is  reliably  broadcast  to  all  replicates. 

(d)  The  values  of  all  sensors  arc  reliably  disseminated  to  all  processors.  Each  processor  then  chooses  some  represen¬ 
tative  data  value  (presumably  derived  from  the  ensemble  of  sensor  readings)  as  input  for  its  function  replicate. 

The  first  alternative  (a)  is  clearly  not  conducive  to  input  congruence  in  that  there  is  no  coordination  of  sensors — each  sensor 
delivers  a  value  independent  of  the  other  sensors,  and  those  values  may  be  arbitrarily  far  apart.  The  second  alternative 
(b)  appears  to  gain  input  congruence  at  the  cjrpensc  of  providing  less  fault  tolerance — the  chosen  sensor  becomes  a  critical 
single  point  of  failure.  The  cross-strapping  approach,  however,  generally  offers  no  advantage  for  input  congruence — wires 
break  and  output  drivers  go  out  of  tolerance  (an  intuitively  appealing  presentation  of  this  scenario  may  be  found  in  [12]). 
The  last  two  alternatives,  (c)  and  (d),  are,  in  fact,  valid  means  of  assuring  input  congruence.  Their  validity  relies  upon  the 
term  “reliable”  as  it  applies  to  the  dissemination  of  data  in  a  network  of  processors  connected  by  some  communications 
mediuni.  Of  course,  approach  (c)  is  still  vulnerable  to  the  failure  of  the  single  sensor. 

1.1  Reliable  Dissemination  Through  Agreement 

In  a  context  characterized  by  faults  of  a  totally  unpredictable  nature,  the  mechanism  by  which  the  reliable  dissemination 
of  data  is  achieved  is  through  an  agreement  protocol.  In  the  tenninology  of  sucli  protocols,  a  General  (the  transmitting 
process)  disseminate.^  a  value  to  all  Lieutenants  (the  receiving  processes).  The  receivers  must  then  engage  in  several  rounds 
of  message-exchange.  At  the  end  of  those  rounds  the  receivers  may  infer  the  value  transmitted,  if,  indeed,  the  transmitter 
is  non-faulty.  Otherwise,  the  receivers  may  agree  upon  a  null  value  which  indicates  a  faulty  transmission.  More  specifically, 
agreement  requires  that  two  conditions  be  met: 

Agreeiiieaf  1:  All  non-fanity  recipient  processes  agree  on  the  same*  x'alue. 

Agreement  2:  If  the  transmitting  process  is  non-faulty,  all  non-faulty  recipients  agree  on  the  ^•aluc  transjnit  ted. 

In  the  absence  of  faults,  exact  agreement  is  trivially  achieved  by  the  transmitter's  broadcast  of  the  same  data  value  to  all 
receiving  processes.  In  the  presence  of  faults,  the  possibility  of  faulty  behavior  by  any  process,  or  possible  corruption  of  any 
data  message  by  the  conimiinications  network,  transforms  a  trivially  solved  problem  into  one  which  is  decidedly  non-trivial. 
l)ot.li  conceptually  and  in  terms  of  the  resources  required  to  achieve  a  solution.  Bit-by-bit  agreement,  witli  no  assumptions 
at)0(it  failure  mo<les,  may  be  «acbievod  by  a  Byzantine  agreement  protocol  (13).  Such  protocols  require  substantial  connectivity 
of  the  commtmications  network  (to  avoid  the  forwarding  of  data  through  fatilty  processors),  many  rounds  o'"  message-passing 
(to  assure  that  faulty  processors  cannot  contribute  to  the  agreement  value),  or  message  authentication  through  cryptographic 
means  or  througlj  error-detection  co<hng  techniques  (to  limit  the  degree  of  faulty  behavior),  Wc  note  sevo:al  salient  facts 
about  exact  Byzantine  agreement: 

1.  The  system  mvist  be  sync/tronoiw{lO].  Intuitively,  a  synchronous  protocol  permits  the  determination  ol  whether  or  not 
a  remote  process  has  crashed  or  is  simply  slow. 

2.  .\  system  of  n  processes  (not  utilizing  authenticated  messages)  can  bo  made  resilient  to  the  failure  of  t  processes, 
provided  tlu.t  t  <  f  [13|. 

3.  At  least  f  +  l  rounds  of  message  passing  arc  required  for  exact  Byzantine  agreement  under  the  most  genera)  a.ssumptionsjD] 
Tlie  original  Byzantine  agreement  aIgorithm[l3]  roquirctla  total  of  0(n*'*^’)  mes.sages:  the  best  algorithm[6].  in  the  worst 
case,  requircc  0(nf.  +  i^)  messages. 

A  scan  of  these  facts  leads  one  to  the  conclusion  that  a  Byzantine  agreement  protocol  is  typically  extremely  expensive  in 
terms  of  replicated  system  components  and  communication  bandwidth. 

In  tlic  context  of  the  system  architectures  ol  Figure  1,  agreement  \wuld  be  utilized  to  disseminate  sensor  values  in  cases 
|c)  and  (d).  In  ca.se  (c),  however,  even  with  the  reliable  data  dissemination  provided  by  an  agreement  protocol,  the  entire 
system  is  vidnorablc  to  inaccuracy  of  the  sole  sensor — erroneous  sensor  output  could  be  reliably  broadcast  to  all  processors, 
••esulting  in  unanimous  consent  on  an  outptit  wliich  is  erronoou.s.  In  contrast,  consider  case  (d)  in  which  each  processor  could 
serve  .as  the  transmitter  in  a  Byzantine  agreement  protocol  (conceptually,  one  would  envision  four  protocols,  each  with  a 
different  process  as  transmitter,  concurrently  in  operation).  At  the  conclusion  of  these  (expensive)  protocols,  each  processor 
would  know  the  values  of  all  four  sensors,  and  could  apply  some  (application  specific)  selection  or  averaging  algorithm  to 
choose  a  single  “sensor  value”  as  input  to  its  function  repucate.  The  validity  of  this  scheme  rests  upon  the  facts  that  all 
non-faulty  proce-s.sor.s  must  have  the  .same  set  of  sensor  data  \'alue.s  a.s  a  consequence  of  the  agreement-based  dissemination 
anfl  tliat  the  selection  or  averaging  algorithm  is  the  same  at  all  prore.ssors. 
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1.2  Approximate  Agreement 

An  alteniative  approach  to  providing  data  to  the  function  replicates  of  Figure  1(d)  is  through  approximate  agreement.  That 
is,  we  require  that  all  non-faulty  processors  derive  an  input  value  which  must  be  ‘^dose  to”  the  value  derived  by  any  other 
non-faulty  processor,  and  that  value  must  be  within  the  range  cf  the  set  of  non-faulty  sensor  values.  Informally  speaking, 
these  requirements  are  met  by  the  approximate  agreement  protocol  developed  by  Dolev  ei  of.  [7].  That  protocol  is  intended 
to  serve  a  network  of  n  processors,  at  most  f  <  f  of  which  may  be  faulty.^  The  maximum  difference  between  any  two  final 
agreement  values  must  be  no  larger  than  some  toleranccy  c,  a  fundamental  parameter  of  the  protocol.  The  apiMtndmate 
agreement  protocol  operates  as  shown  in  Figure  2.  This  example  depicts  a  four  processor  system  (n  =  4  and  f  =  1)  in 
which  the  first  processor  is  assumed  to  be  faulty.  During  each  step  of  the  protocol,  each  processor  maintains  its  current 
estimate  of  its  agreement  value;  this  is  represented  by  the  horizontal  array  at  the  top  of  the  figure.  The  first  action  of  a 
step  of  the  protocol  is  each  processor’s  broadcast  of  its  value  to  all  processors  (induding  itself).  In  Figure  2  (a),  the  (t,;) 
entry  of  the  matrix  in  the  center  represents  the  value  received  by  Pi  from  Pj  at  the  end  of  this  roimd  of  message  passing. 
Ft,  the  faulty  processor,  is  shown  sending  difierent  values  to  different  processors,  and,  as  illustrated,  its  multiset  of  received 
values  is  irrelevant — a  faulty  processor  will  not,  in  gener^,  adhere  to  the  approximate  agreement  protocol.  Elach  processor 
then  applies  the  same  value  update  algorithm  to  its  multiset  of  received  values  (i.e.,  its  row  of  the  matrix)  as  shown  in 
Figure  2(b).  For  the  case  of  a  synchronous  system^  that  update  procedure  involves  sorting  the  multiset,  discarding  t  values 
on  each  end  of  the  range  of  the  multiset,  retaining  the  first  and  every  t-th  successive  elements  thereafter,  and  taking  the 
arithmetic  mean  of  the  values  so  retained.  It  can  be  shown  that  a  single  application  of  the  update  function  at  all  good 
processors  will  effectively  reduce  the  diamelei^  of  the  multiset  of  values  held  by  good  processors  by  a  factor  of 


d  = 


1  n  -  2<  -  1 1 


+  1. 


Since  n  >  this  factor  must  be  at  least  2. 


We  note  several  fundamental  differences  between  approximate  agreement  and  (exact)  Byzantine  agreement:  In  Byzantine 
^reement,  the  agreement  value  is  identical,  on  a  bit-by-bit  basis,  for  all  non-faulty  processors.  In  approximate  ^reement, 
the  agreement  value  derived  by  any  non-faulty  processor  must  be  within  €  of  the  agreement  value  of  any  other  non-faulty 
processor.  We  feel  confident  that  the  approximate  agreement  is  all  that  is  required  in  many  specific  applications  (and,  in 
fact,  it  may  be  desirable  to  avoid  bit-by-bit  agreement  in  an  N-version  programming  sy8tem|2]).  Moreover,  (exact)  Byzantine 
agreement  is  not  even  possible  in  an  asynchronous  system,  but  approximate  agreement  is  easily  implemented  without  global 
synchronization. 
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(a)  One  Round  of  the  Protocol 


(b)  The  Update  Procedure 


Figure  2:  The  Approximation  Protocol  (n  =  4) 


1.3  Halting  the  Approximate  Agreement  Protocol 

Processors  which  are  participating  in  a  synchronous  approximate  agreement  protocol  each  determine  a  halting  round 
independently.  This  follows  from  the  fact  th^  a  non-faulty  processor,  P^,  starting  vdth  an  initial  multiset  of  values  Vj, 
can  only  pessimistically  assume  that  the  diameter  of  its  multiset  will  be  decreased  by  a  factor  of  d  on  each  round.  Thus, 


'Thus  if  1  =  1,  there  must  be  at  least  three  additional  ‘good”  processors,  and  if  (  =  2,  there  must  be  at  least  five  addittonal  non-faulty  proceaaors, 
etc. 

^The  diameter  of  a  multiset  of  real  numbers  is  the  absolute  value  of  the  difference  between  the  largest  and  smallest  dements  of  that  imltiset. 
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processor  Pi  anticipates  executing 

H!  =  [log.  ( 

rounds  of  the  protocol  in  order  to  ensure  that  the  multiset  of  values  held  by  any  good  processor  has  a  diameter  no  larger 
than  €.  Two  additional  points  concerning  this  halting  technique  are  relevant;  First,  on  the  round  ^fter  which  a  non-faulty 
processor  halts,  it  broadcasts  a  halt  tag  with  its  agreement  value  on  the  next  round  of  the  protocol;  after  receipt  of  a  tagged 
value  from  a  baited  processor,  another  processes  will  a>ntinue  to  use  that  tagged  valu'^  as  ihe  value  trausxnitted  (without 
receipt  of  an  actual  message).  Secondly,  a  processor  whose  value  is  not  received  within  a  timeout  interval  (presumably 
representative  of  the  maximum  message  transmis^cm  time),  will  be  assumed  to  have  send  some  arbitrary  default  value. 

The  fundamental  difficulty  with  this  halting  technique  defined  by  is  that  Ifi  can  be  arbitrarily  large;  i.e.,  faxdiy 
processors,  by  ike  initial  broadcast  of  values  which  are  arbitrarily  far  removed  from  actual  values,  can  arbitrarily  enlarge  the 
diameter  of  the  initial  multisets  of  good  processors,  and  consequently,  arbitrarily  delay  convergence. 


diameter(V;)y 


2  Accelerated  Convergence 

In  this  section  we  will  develop  and  empirically  evaluate  two  approaches  to  faster  convergence;  adaptive  halting  and  initial 
multiset  editing.  The  degree  to  which  each  approach  succeeds  depends  on  knowledge  of  the  expected  behavior  of  the  system 
in  which  the  protocol  operates.  We  adopt  the  following  assumptions  about  the  system; 

IiiUialization:  Each  good  processor  independently  draws  an  initial  value  (i.c..  will  read  its  sensor)  from  a  distribution  of 
“good  values”.  For  the  purposes  of  our  simulations,  we  define  this  distriliution  to  be  A''(0, 1),  the  standard  normal 
distribution. 

Broadcast:  Whenever  a  faulty  processor  transmits  a  message,  it  sends  a  value  drawn  independently  from  a  distribution  of 
“bad  values”.  We  utilize  N{Q.ci) :  o  >  1.0  as  the  family  of  bad  value  distributions. 

We  make  no  distinction  between  the  failure  of  a  processor  and  the  failure  of  a  sensor;  the  two  constitute  a  single  entity 
as  far  as  fault  behavior  is  concerned.  In  the  following  discussion,  when  we  refer  to  a  ‘"failed  processor”,  we  actually  refer 
to  the  processor/sensor  pair.  A.U  faults  are  assumed  to  be  independent  of  previous  fault  behatdor  and  the  current,  state  of 
the  system.  Our  model,  therefore,  does  not  address  the  notions  of  correlated  faults  or  of  processors  failing  in  coordinated 
fashion.  We  term  this  model  the  two-faced  independent  fault  model,  and  we  utilize  this  model  in  the  remainder  of  this  paper. 

Note  that  values  transmitted  by  faulty  processors  share  the  same  mean  with  the  values  chosen  by  good  processors.  This 
facet  of  the  model  was  intended  to  represent  worst-case  behavior — faulty  values  chosen  from  a  distribution  whose  mean  is 
substantially  different  from  the  mean  of  the  distribution  of  good  values  are  easily  discarded  by  the  approximate  agreement 
update  algorithm. 

2.1  Adaptive  Halting 

The  adaptive  halting  procedure  is  outlined  below: 

•  Let  Vf  be  the  multiset  of  (good  and  bad)  values  held  by  processor  P,  at  the  conclusion  of  the  r-th  round  of  the  protocol. 
Let  Hi  be  Pi's  computed  halt  round  at  the  end  of  the  r-th  round  of  the  protocol,  ff-  is  the  previously  defined  static 
halt  round  for  P,  as  defined  in  the  original  protocol. 

•  After  accumulating  in  the  broadcast  phase  of  round  r  +  1,  compute 

temp.  ^  max  (o.  [log, 

•  Set  Hl*^  to  min(P’,^,  r  -|- 1  +  tempj. 

The  obvious  goal  of  this  approach  is  to  exploit  the  round-by-round  variation  in  Vf  to  achieve  much  faster  convergence 
than  that  guaranteed  by  the  pessimistic  convergence  factor  d.  For  example,  suppose  that  a  single  faulty  processor  (Pi),  in 
a  4-proccssor  system,  (Pi,  Pj,  Pj,  P,},  consistently  broadcasts  a  common  value  which  is  significantly  different  from  the  valid 
sensor  values  on  the  first  round.  The  original  protocol  will  then  compute  the  same  large  halt  rounds  for  all  good  processors 
based  on  their  common  inflated  initial  multisets.  Moreover,  the  agreement  values  computed  by  the  good  processors  on 
the  first  round  will  agree  exactly,  and  thus  all  rounds  after  the  first  will  be  unnecessary  overhead.  If  Pi,  at  some  later 
round,  consistently  broadcasts  a  common  value  relatively  close  to  the  agreement  valu-^s,  the  the  adaptive  halting  procedure 
will  then  provide  quicker  termination.  Adaptive  halting  can  be  shown  not  to  invalidate  any  of  the  functional  correctness 
properties  of  the  original  approximate  agreement  protocol- 

Figure  3  presents  the  results  of  adaptive  halting  applied  to  four  processor  and  seven  processor  systems.  As  in  all 
experiments  presented  in  this  paper,  €  =  0.1.  Larger  values  of  e  (all  other  system  parameters  remaining  constant)  merely 
shift  the  plots  downward,  and  smaller  values  shift  the  plots  upward.  One  of  the  processors  in  the  four  processor  system,  and 
two  of  the  processors  in  the  seven  processor  system,  exhibit  two-faced  independent  failure.  The  vertical  axis  of  the  plots  is 
the  mean  halting  round  for  a  Monte  Carlo  simulation  (1000  replications)  of  the  protocol  in  operation  for  a  specific  value  of 
a.  The  halting  round  on  any  replication  is  defined  to  be  the  largest  halt  round  for  all  non-faulty  processors. 

The  results  are  disappointing  but  intuitiuve.  Adaptive  halting  provides  negligible  gains  over  the  traditional  pessimistic 
approach.  In  effect,  the  probability  that  a  faulty  process  broadcasts  a  commmon  “nearly  good”  value  is  so  small  that  the 
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(a)  (4. 1.0.1)  System  (b)  (7.2.01)  System 


Figure  3:  Adaptive  Halting 


adaptive  halting  round  only  rarely  becomes  smaller  than  Hi  for  all  non-fauliy  processors.  The  trend  towards  less  gain  in 
larger  systems  is  also  intuitive;  adaptive  halting  succeeds  only  when  bad  values  are  somewhat  consistently  disseminated  to 
good  processors,  and  the  greater  the  number  of  processors  the  more  difficult  it  is  to  lie  consistently  under  the  two-faced 
independent  failure  model.  We  would  expect  that  adaptive  halting  would  be  valuable  only  in  a  failure  regime  characterized 
by  processors  which  operate  correctly  moat  of  the  time  but  which  fail  wildly  for  only  brief  intervals.  Thus  we  reject  adaptive 
halting  as  a  general  approach  for  accelerated  convergence  and  turn  our  attention  to  the  possibility  of  editing  sensor  data  to 
achieve  faster  convergence  without  introducing  error  into  the  agreement  protocol. 

2.2  Editing  the  Initial  Multiset 

If  we  consider  the  application  of  approximate  agreement  in  a  real-time  fault-tolerant  control  system,  we  gain  some  leverage 
by  which  the  halting  difficulty  may  be  overcome.  Figure  4  illustrates  the  basic  form  of  the  control  system  software.  We 


Figure  4:  Control  Loop 

assume  that  the  control  loop  is  frequently  executed — a  30Hz  loop  would  not  be  uncommon.  A  consequence  of  this  frequency 
is  that  the  sensor  readings  will  presumably  not  change  ‘Hoo  much^  on  successive  iterations.  For  example,  if  the  sensor 
were  an  aircraft  accelerometer,  the  dynamics  of  the  aircraft  and  the  integrity  of  the  wrframe  itself  would  impose  bounds 
on  the  rate  at  which  acceleration  can  change.  Therefore,  w  assume  that  certain  application-specific  criteria  can  be  used 
to  rationally  edit  bad  data  values  from  the  initial  multisets  accumuleited  in  the  first  round  of  the  approximate  agreement 
protocol. 

In  order  to  verify  that  data  editing  can  provide  substantial  performance  benefits,  we  consider  two  theoretical  bounds  on 
the  best  possible  halting  behavior  of  an  approximate  agreement  protocol. 

Absolute  Optimal  The  earliest  possible  halting  would  be  achieved  by  globally  monitoring,  on  each  round,  the  agreement 
values  computed  by  all  good  proces8<»s.  When  the  diameter  of  that  multiset  becomes  less  than  c,  halt.  Of  course, 
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there  is  no  practice  way  to  discriminate  between  faulty  and  non-faulty  processors  or  to  globally  monitor  agreement 
values  (although  global  snapsbocs[4,14|  could  be  used,  at  great  expense,  to  monitor  the  values). 

Practical  Optimal  If  we  compute  halting  rounds  based  on  the  initial  multisets  of  values  from  only  nondaulty  processors, 
we  achieve  the  best  possible  halting  performance  for  the  original  approach  to  halting.  Note  that  we  still  cannot 
discriminate  absolutely  between  good  values  and  bad,  and  thus,  this  bound  is  also  not  directly  implementable. 

Figure  5  demonstrates  that  there  is  an  appreciable  gap  between  the  stopinng  behavior  of  the  original  protocol  (the  upper 
line  in  both  '•^ses)  and  both  idealized  techriqncc.  No*^  specificallv  that  the  separation  between  the  original  algorithm’s 
performance  and  that  of  the  practical  optimal  technique  is  6ve  or  six  rounds  of  message  passing  (and  updating)  foi  relati\'cly 
large  values  of  a  (in  both  systems).  That  gap  translates  into  the  potential  for  substantial  real-time  savings  via  editing  the 
initial  multiset.  If  we  could  omnisciently  edit,  i.e.,  remove  only  faulty  processors’  values  from  the  initial  multisets,  the 
halting  behavior  would  be  exactly  that  of  the  practical  optimal  lK)und.  The  separation  between  the  practical  optimal  bound 
and  the  absolute  optimal  indicates  the  price  we  pay  for  not  being  able  to  identify  failed  processors  as  the  algorithm  executes. 
For  both  four  and  seven  processor  systems,  that  gap  is  roughly  1.5  rounds. 

The  intria/  muJtisei  editing  approach  is  based  on  wild-point  editing  as  outlined  below; 

•  Let  be  the  mean  of  the  distribution  of  good  sensor  values,  and  let  be  its  standard  deviation.  Let  V{  =  {uj , . . . ,  t),,} 

be  the  multiset  of  values  obtained  by  processor  P,  in  the  broadcast  phase  of  the  initial  round  of  the  approximate 
agreement  protocol. 

•  For  all  Vj  6  V',  if  -  pd  >  ^Hen  replace  Vj  with  nc- 

•  Calculate  H}  based  on  the  edited  initial  multiset. 

In  an  operational  system,  historical  data  could  be  used  to  provide  statistical  estimates  of  f.ta  and  and  the  threshold 
parameter  0  would  be  chosen  according  to  the  needs  of  the  application.  There  is  an  important  trade-off  here.  The  larger 
the  value  of  the  less  likely  valid  data  is  to  be  discarded  and  the  slower  the  rate  of  convergence.  Conversely,  smaller  0 
implies  faster  convergence  at  the  possible  expense  of  an  error.  Here  an  error  actually  means  non-convergence;  i.e.,  either 
the  diameter  of  the  final  agreement  values  of  non-faulty  processors  is  greater  than  c  or  an  agreement  value  falls  outside  of 
the  initial  range  of  sensor  values  read  by  non-faulty  processors. 

Figure  6  shows  the  result  of  initial  multiset  editing  applied  to  four  processor  and  seven  processor  systems.  The  thresliold 
parameter,  0,  is  varied  between  1.0  and  3.0. 

Results  of  Figu.''e  C  must  be  evaluated  in  the  light  of  the  possibility  of  errors  which  may  be  produced  by  the  rejection 
of  valid  data.  Unlike  the  ineffective  adaptive  halting  proce<h!rc,  data  editing  may  result  in  non-convergence— clearly,  the 


(a)  (4,1,0.!)  System  (b)  (7, 2, 0,1)  System 
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Figure  5:  Bounds  on  Performance  of  Editing 

possibility  of  d^sc^u:(ling  data  from  a  good  s«isor /processor  perverts  any  formal  correctness  argument  developed  for  standard 
approximate  agreement.  Tabic  1  shows  the  worst-case  performance  for  a  given  choice  of  0  in  both  systems.  Worst-case 
performance  here  is  simply  the  highest  percentage  of  errors  for  1000  replications  for  any  a. 

We  make  the  following  two  inferences  from  Figure  6  and  Table  1: 

•  Halting  performance  which  is  significantly  better  than  practical  optimal  (  5  <  1.0)  can  be  achieved— but  only  at  the 
expense  of  a  non-negligible  error  rate. 

•  With  a  reasonably  large  rejection  threshold  parameter  =  2  or  3),  halting  performance  asymptotically  equal  to  the 
practical  optimal  is  achieved  under  the  two-faced  independent  failure  model.  An  experiment  in  which  3  =  2.0  and 
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(a)  Edited  (4,1,0. 1)  System 


Figure  6;  Halting  with  Edited  Initial  Multisets 


a  =  50.0  executed  for  over  three  million  replications  with  only  two  errors. 


3  Concluding  Remarks 

We  have  presented  a  model  of  fault  behavior  under  which  data  editing  can  yield  substantial  performance  benefits  without 
introducing  appreciate  error  into  the  approximate  agreement  protocol.  Under  our  model,  a  rejection  threshold  of  two  or 
three  standard  deviations  from  the  mean  of  the  distribution  of  good  values  leads  to  near  optimal  performance  without 
introducing  appreciable  error  into  the  system.  We  postulate  that  historical  data,  accumulated  during  the  operation  of  a 


System  1  4-1 

7-2 

Error  Rate 

Error  Rate 

0.5 

27.2 

11.2 

1.0 

4.8 

0.6 

1.5 

0.7 

0.1 

2.0 

0.1 

0.0 

2.5 

0.0 

0.0 

3.0 

0.0 

0.0 

Table  1:  Errors  Induced  By  Editing 


control  loop,  may  be  used  as  a  basis  for  this  editing.  Clearly,  the  editing  tends  to  damp  the  control  system  somewhat,  but 
a  legitimate  change  in  sensor  value  will  be  accommodated  immediately. 

We  are  in  the  process  of  the  analytic  modeling  of  the  editing  procedure.  This  work  will  allow  validation  of  the  simulation 
results  and  permit  rapid  extrapolation  into  new  system  contexts.  The  issue  of  how  one  chooses  e  and  0  is  clearly  application 
specific.  We  are  currently  beginning  to  examine  real  sensor  (accelerometer)  data  to  better  understand  how  that  choice 
impacts  upon  the  end-to-end  performance  of  the  control  system  (e.g.,  if  the  loop  iteration  frequency  is  sufficiently  high, 
perhaps  an  occasional  agreement  error  would  have  no  api^eciable  effect  on  the  performance  of  the  system).  The  issue  of 
the  degree  of  damping  induced  by  the  data  editing  will  also  be  examined  in  the  light  of  real  sensor  data. 

We  postulate  that  approximate  agreement  can  be  a  useful  construct  in  the  design  and  implementation  of  real-time  reliable 
systems.  Further,  ad^ting  the  basic  protocol  in  response  to  knowledge  about  expected  input  values  and  the  demands  of 
the  application  is  likely  to  be  essential  in  order  to  meet  performance  specifications. 
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R.Busser,  US 

What  is  your  view  on  the  “N-version  software  as  a  technique  for  tolerance  to  generic  software  errors"  controversy? 

Author's  Reply 

My  view  is  to  use  it  at  your  own  risk.  Knight-Leveson  provided  evidence  that  coincident  error  phenomena  can  occur  in 
the  "moderate"  reliability  range  (version  reliability  "  10“^,  10'^).  But  even  extrapolating  successful  experiments  in  this 
range  to  an  "ultra"  level  (10~^)  cannot  be  justified.  Hardware  failure  independence  relies  on  accepted  physical 
principles,  but  will  never  be  "proved”  statistically  due  to  the  number  of  tests  required.  Software  development  has  no 
such  luiown  principles. 
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ABSTRACT; 

Tbe  need  for  protection  against  oominxi-iacide  failures,  in  Hardware  and  in  Software,  as  well  as  tne  need  to  cut 
Hardware  costs  and  oanplexit;,  has  led  to  redundant  asmcbronous  ardutectures. 

Tlie  resulting  random-phase  sampled-data  systems  are  loosely  ooupled,  reducing  fault  propagatioabut  need  to 
maKe  baugeneous  decisions  whenever  oenain  event  oamhinations  occur. 

Since  decisions  are  basioauy  boolean  operations,  a  method  has  been  developed  to  achieve  homogeneous  agreement 
on  discrete  signais,without  imposing  constraints  on  input  or  architectural  characteristics  to  the  system 
designer. 

The  method  solves  the  critical  problem  of  synchronized  change  of  operational  mode  in  avionic  systems,  where  a 
safe  'ail  or  ncsie'  way  of  making  decisions  is  of  primary  importance. 


macDucnai 

Hodem  technology  for  Quidanoe,  Weapon  and  Superviscry  Systems  in  Aircraft  and  HissUes  is  nowadays  trying  to 
meet  the  ever-growing  demand  for  performanoe,  together  with  eatensive  Fault-tolerance  and  operational  safety 
characteristics. 

Distributed  computing,  organizing  the  raw  processing  power  of  a  number  of  microprocessors  in  a  synergetic 
stnictura  provides  a  way  to  achieve  considerable  performances,  allowing  to  implement  muiupie  redundancies, 
as  well  as  crasstDomtaring  and  related  fault  management  policies,  to  achieve  an  overall  high  degree  of  Fault- 
tolerance. 

The  use  of  multiple  redundancy  has  brought  forward  the  major  issues  of  ocmmon  Mode  FaUures;  capable  to  defeat 
tne  System. 

The  availability  of  several  microprocessor  families  with  comparable  ocmputing  power  gives  now  the  opportunity 
to  incorporate  dissimilarity  in  the  redundancy  scheme,  for  instance,  allowing  different  processors  to  monitor 
each  other. 

COraoKh  Hole  Failures  not  covered  by  dissimilarity  are  those  caused  by  particular  input  data  values,  yielding 
wrong  results,  due  to  flaws  in  the  Hardware  ot-  in  Software.  Since  any  computing  system  is  basically  a  sampled- 
data  system,  this  may  happen  in  all  nodes  if  an  nodes  are  sampling  data  exactly  at  the  same  instant,  la.  if 
tne  system  is  synchronous. 

TO  overoomc  this  Asynchronous  Distributed  Architectures  have  been  developed,  where  the  nodes  are  deliberately 
out  of  phase  by  a  random  percentage  of  tne  basic  cycle  rate  (framel  that  remains  however  the  same  for  all 
nodes  ttsoChrtxiysml  to  keep  the  system  to  a  manageable  complexity. 

The  chances  that  the  flaw  shows  up  In  aU  nodes  are  reduced  and  ,  as  a  side-effect  benefit,  the  System  Design 
Is  forosd  towards  loosely-coupled  Architectures  effective  in  fault-propagation  preventloa 
Another  major  advantage  of  such  architectures  is  the  absence  of  critical  common  Hardware,  in  charge  of 
providing  all  nodes  with  synchronizing  signals 

The  use  of  distributed  Architectures  brings  in  problems  the  most  obvious  of  which,  and  certainly  not  the 
least  significant  is  that  the  processors  or ,  more  generally,  the  computing  nodes  will  have  to  communicate 
with  each  other  to  permit  both  synergy  and  cross-checking 

It  IS  actually  essential  for  the  System  to  ensure  that  different  nodes  do  not  generate  contrasting  commands  or 
messages  or  take  decisions  in  opposite  directions 


SYHCHROSEATIOM  la^Mii.-atinnt  the  Analogue  Case 

It  IS  relatively  easy  to  synchronize  (or  consolidate  ,  or  equalizel  a  single  analogue  datum  starting  from 
signals  ooming  from  multiple  asynchronous  sources 

Several  techniques  such  as  Hedian  Selection,  plain  or  weighted  Averaging,  Distance  Compensation  with 
ru'jirsii  Dyi.,1-1^  w»icr.  or  combinations  of  the  above  (up  to  the  complexity  of  a  Kalman  Filter)  have  been 


i 
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(levelopea  and  are  widely  used  to  calculate  in  each  aiynchronous  node  a  single  datum  that  is  sufficiently 
similar  to  that  calculated  in  any  other  node. 

These  techniques  can  he  easily  made  (or  are  intrinsically)  insensitive  to  the  failure  of  any  single  node  , 
incorporating  faulty  node  datum  isolation,  and  in  general  guarantee  that  the  output  datum ,  for  each  node,  is 
constantly  drifting,  imre  or  less  smoothly,  towards  a  datum  that  is  continuously  calculated ,  according  to  the 
technique  used,  as  an  a]pproprute  “average"  of  all  vaUd  input  signals;  this  implies  they  are  intrinsically 
robust  and  safe. 

Purtbenncre,  in  multiple  sampled  data  systems,  the  difference  in  the  sampled  values  in  any  node  pair  cannot 
esoeed  an  upper  bound,  rigorously  determined  by  the  signal's  dynamics  and  the  worst-case  delay  in  sampling 
from  one  node  to  another.  In  general,  tnough,  this  upper  found  is  significant  when  the  system  is  sampling  data 
with  a  basic  cycle  that  is  so  slow  to  be  comparable  with  Shannon's  Theorem's  minimum  rate;  In  practical 
systems  a  basic  cycle  at  least  faster  than  that  at  least  by  an  order  of  magnitude  is  no  more  than  sensible 
practice. 


syaaiBOMlZa'noii  gr  cwisoiidauoni;  me  Discrete  case 

Treating  signals  with  boolean  values  obviously  prevents  the  use  of  techniques  such  as  averaging  or  filters, 
actually,  considering  the  signals  in  continuous  time,  the  techniques  used  for  analr«ue  signals  are  capable  to 
converge,  if  the  signals  show  a  steady  state  of  sufficient  durauoa  but  the  algorithm  output,  with  a  final 
threshold  to  obtain  again  a  boolean,  yields  unacceptable  transient  differences;  causing  a  subset  of  nodes  to 
consolidate  a  boolean  opposite  to  tne  other  nodes. 

Another  difficulty  is  that,  treating  booleans  casing  from  asynchronous  sources  in  the  boolean  domain,  no  upper 
bound  can  be  established  that  limits  the  difference  in  output  from  one  node  to  tne  others.  The  instantaneous 
difference  in  the  output  from  any  two  nodes  can  be  either  oz  or  lOOZ,  and  the  only  type  of  error  upper  limit 
that  can  be  determined  is  in  terns  of  phase  and  duration  of  the  output  inequality. 

Inequality  can  be  caused  in  fact  by  various  mechanisms: 

-  The  sampling  process  applied  to  discretes  causes  the  following; 

.  Pulses  shorter  than  a  full  basic  cycle  can  remain  undetected  in  a  subset  of  the  nodes. 

.  Every  sampled  level  is  stretched  in  durauon  to  an  integer  nmtxr  of  basic  cycles  iframesi 

-  Different  phase  in  sampling  causes  the  following. 

■  Opposite  levels  sampling  on  transition  boundary 

.  Intemode  communications  appear  with  additional  delay  at  each  node 

.  Any  input  pulse  may  he  measured  with  a  l-frarae  duration  difference  in  any  node  pair. 

.  Voting  and  threshold  mechanisms  of  any  Kind  fall  to  consolidate  consistently  in  all  nodes. 

A  typical  example  snowing  voting  techniques  inadequacy  for  this  case  follows: 

Consider  four  nodes,  Ct.C4  .  with  a  basic  frame 
cycle  T  ,  where  Cl  is  synchronized  with  an 
absolute  frame  of  period  t,  while  C2.C3,C4  are 
out  of  phase  by  1.2  and  3  times  t/4  , 
resgiectively.  Let  us  assume  that  the  algorithm  is 
defined  as: 


If  3  out  of  4  among  the  available  signal  sources 
agree,  the  output  is  the  agreed  leveL  otherwise 
it  remains  unchanged  from  the  previous  frame. 

The  4  sources  are  the  direct  input  and  the  signals 
read  by  the  other  three  nodes,  and  It  is  assumed 
that  the  time  from  sampling  the  input  and 
transmission  to  the  other  nodes  is  short  with 
respect  to  the  frame. 
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It  becomes  evident  that  if  a  pulse  of  duration  i/2t<a<3/4t  starts  just  before  the  start  of  the 
absolute  frame,  it  will  be  directly  sampled  by  Ct,C2  and  C3,  but  not  by  C4.  But  ci.C3  transmit  their  sample 
to  each  other  and  to  C4  before  C4  samples  its  inputs.  The  result  is  that  Cl  and  C2  will  not  satisfy  the 
algorithm  condition  for  agreement,  while  C3  and  C4  will,  even  If  C4,  for  instance,  taKes  its  decision  in 
contrast  with  its  own  sampled  value . 

Threshold  techniques  fail  as  well,  since  they  are  basically  voting  on  the  event  of  a  certain  time  being 
elapsed  with  certain  conditions,  and  time  measurements  can  differ  by  one  frame,  causing  the  threshold  to  be 
wmeedwl  only  m  a  subset  of  the  nodes  in  the  asynchronous  case 


syiPJQirraTrw  (FwaiE  Tim  nature  of  the  Pttailem 

The  majn'  problem  In  multlmdal  systems  is  that  of  synchmilzaticn  of  operational  mode  changes  in  consequence 
of  events  of  discrete  nature  external  switches,  reaching  of  thresholds,  timeouts  etc.  In  synchronous  systems 
,  typically  equipped  with  a  *data  input  interrupt",  all  nodes  are  sampling  data  at  the  same  instant,  and  thus 
differences  may  only  be  due  to  malfunctions.  Transmission  of  samples  from  one  node  to  others  is  synchronized 
as  weU,  and  the  transmission  delay  is  a  Known  constant,  in  absolute  terms.  Appropriate  algorithms  guarantee 
discrete  signals  consolidation  in  a  minimum  number  of  frames,  simultaneously  in  all  nodes 

In  Asynchronous  multinodal  systems  this  holds  no  longer.  The  problem  changes  from  the  selection  of  an 
algorithm  that  consolidates  the  output  in  the  minimum  number  of  frames  to  the  use  of  an  algorithm  that  allows 
consolidation  at  all. 

In  most  such  systems,  discrete  events  are  in  fact  the  Key  data  on  which  decisions  are  made  about  the 
operational  mode  the  whole  system  should  assume.  Examples  are  Manoeuvre  Mode,  Attitude  Hold,  Trim,  Trim 
Synchronization,  Automatic  transiuons,  and  so  on.  Hote  how  a  mode  change  of  this  sort  causes  in  most  cases  a 
re-inltiallzatlon  of  long-term  datums  in  the  system's  Control  Laws,  and  from  this  point  of  view  a  transition 
has  long  memory,  or  "latches",  in  other  cases  a  true  latching  process  is  effecuvely  required. 

This  means  that,  for  each  node  consolidating  a  transltloa  the  following  processing  is  altered. 

This  maKes  a  Synchronized  OonsoUdauon  of  the  mode  transiuon  compulsory,  putting  time  response  at  a  lower 
priority.  The  actual  need  is  in  fact  to  ensure  that  the  whole  system  changes  its  operational  mode  in  the  same 
way,  or  does  not  change  mode  at  all  In  other  words,  the  priority  is  to  achieve  system's  consistency  at  all 
times.  * 

Systems  with  muiuple  cross-checKing  redundancies  are  particularly  critical  in  this  respect,  since  even 
temporary  moonsistencies  leading  to  different  operational  modes  in  different  nodes  can  cause  the  checKs  to 
detect  allures  (that  actually  do  not  exist)  that  win  generate  cut-out  commands.  This  occurs  for  certain  when 
the  decision  result  is  latched  in  a  subset  of  the  nodes. 

Tb  overcome  this;  the  only  alternative  to  a  proper  synchronizing  algorithm  Is  to  decrease  the  cross-checKlng 
sensitivity,  reducing  error  detection  time  response  and  redundancy  manag'xnent  performances,  that  is  not 
acceptable  in  most  cases. 


ATfflALASYlimiCUSAICHnSOTiiE 


Let  US  now  consider  a  typical  architecture  with  muiuple  asynchronous  sampling  and  computing  nodes. 

Consider  H  computing  nodes,  CL.CN,  able  to  com¬ 
municate  to  each  other  and  receiving  data  from  the 
outside  world  via  H  sampling  nodes,  S1..SH,  able 
to  provide  fresh  data  to  (XCH  with  a  frequency 
higher  than  the  basic  frame  r  of  the  System 
(equal  in  period  for  all  (Cl  nodes). 

Let  us  assume  that  IS)  refresh  the  data  to  ICI  in 
"broadcast"  mode,  Le.  that  data  is  available  to 
any  node  in  fQ  at  the  same  instant.  Communica¬ 
tions  between  the  nodes  are  assumed  "broadcast"  as 
weU,  and  each  node  is  able  to  transmit  data  also 
to  Itself.  Intemodai  oommunicauon  must  be  such 
to  guarantee  complete  transfer  of  relevant  data 
from  Cl  to  Cj  in  less  than  a  frame  time  t. 
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Eacb  a  will  freeze;  at  tbe  beginning  of  each  of  ita  frames,  and  foe  the  mtlre  frame  duratlm  the  whole  set 
of  input  data,  consisting  of  : 

-  data  from  (SI 

-  data  from  the  other  rudes 

-  data  from  Itself 

and  the  'staleness'  of  any  of  these  data  u  <=  t  . 

Hole  how,  from  the  point  of  view  of  the  computing  nodes  (Cl  the  whole  set  of  data  coming  from  S1,3H  can  be 
considered  simply  a  set  of  external  asynchronous  data,  and  as  such  the  presence  of  the  samplers  IS|  will  be 
Ignored  in  the  following. 

TMsntHanzaTOHicaBiDiiEiML 

Slnoe  each  Cl  is  a  sampler  with  sampling  rate  t,  the  phase  relation  between  Cl  and  CJ  is  in  fact  more  of 
Interest  than  the  phase  relation  of  Si  to  (Cl  tt  is  always  possible,  without  loss  of  generality,  to  rename 
the  members  of  fCI  so  that  Cl  is  the  node  receiving  first  the  new  value  of  a  certain  piece  of  data,  and  all 
other  nodes  C2XN  sample  the  same  data  in  sequence,  with  CH  sampling  with  a  delay  a  with  respect  to  Cl, 
where  OcAtr 

Note  that,  on  the  contrary,  it  Is  important  to  consider  the  timing  of  Internodal  communication,  since  these 
repeat  with  a  period  t  and  thus  have  an  effect  at  the  sampling  rate.  The  Isochronism  of  such  oommunlcatlon 
and  the  sampling  In  all  nodes  ,  even  if  the  transmission  bursts  are  out  of  phase,  is  the  Key  to  a  simple 
sdutlan  to  the  synchronization  problem. 

The  worst  case  of  asynchronlsm  may.  in  virtue  of  the  possibility  to  renumber  the  nodes,  be  simulated  by  an 
even  temporal  distribution  of  nodes  over  the  period  t,  with  the  first  node  synchronous  with  an  absolute 
sampler  of  period  t,  without  losing  generality,  since  sampling  maKes  a  phase  delay  of  t/H  identical  to 
any  other  phase  delay  in  the  range  [O..T1 . 

The  case  of  two  or  more  nodes  in  synchronism  is  simpler  than  the  case  above,  and  is  anyway  covered  by  the 
proposed  method . 

Let  now  to  be  the  generic  absolute  time  of  a  transition  in  a  discrete  input,  externally  generated  or 
produced  by  the  Software  (exceeding  a  threshold,  a  timeout,  or  oomblnatlcxis  of  these  with  other  discretes! 
Due  to  sampling,  each  node  Cl  will  read  the  input  at  absolute  time  tj>:tO,  but ,  for  the  same  reason, 
If  eslsts  at  least  one  node  out  of  phase  with  respect  to  Cl  there  exists  an  infinite  number  of  transitions  . 
with  appropriate  phase  and  duration  ranges,  such  that  for  a  subset  of  IC1  ti  does  not  exist,  le.  a  subset 
of  (Cl  does  not  recognize  the  transition.  This  is  true  for  transitions  shorter  than  t,  and  can  be 
generalized  to  the  leading  or  trailing  edge  of  any  discrete  pulse.  If  the  total  duration  of  the  pulse  is  not 
equal  to  an  Integer  numbs'  of  frames. 

This  means  that  any  measurement  of  an  external  event's  duration  is  subject  to  a  one-frame  possible  difference 
in  any  node  pair,  (tote,  however,  that  the  maximum  difference  in  measurement  between  any  two  nodes  cannot 
exceed  one  fTaroa  since  any  part  of  a  (oulse  longer  than  one  frame  is  certainly  recogmzeable  by  all  nodes. 

Nevertheless,  we  can  conclude  that,  in  an  asynchronous  system,  even  if  ,  in  a  continuous  absolute  time 
reference  the  patterns  of  a  discrete  input  are  similar,  in  the  discrete  reference  system  tied  to  a  single 
node,  the  patterns  transmitted  by  all  nodes  may  show  considerable  difference. 

The  analysis  of  the  problem  with  multiple  trials  In  several  directions  and  bearing  In  mind  the  constraints 
imposed  by  the  real-time  nature  of  the  systems,  has  generated  the  following  requirements  for  a  mode 
synchronization  algn'lthm: 

-  independent  operation:  the  algcrlthm  must  be  the  same  In  all  nodes  and  must  be  executed  independently 
at  the  same  point  In  each  node's  basic  cycle  t. 

-  msensitlvlty  to  noise;  the  algorithm  must  guarantee  a  synchronized  I'esponse  in  the  whole  system ,  even 
in  the  presence  of  fast  and  random  transients  In  the  inputs 

-  pseudo-synchronization  on  output  all  the  nodes  must  synchronize  the  transition  with  a  maximum 
difference  between  each  other  shorter  than  t. 

-  rtSMistness;  it  must  be  impossible  for  any  one  node  to  ignore  a  transition  synchronized  by  other  nodes 
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-  reoonfijuraCility:  tue  algwithm  must  te  easily  extendaWe  to  include  features  UKe  error  detection  and 
faulty  node  oasKing. 

-  efficiency;  Uie  communications  load  between  nodes,  being  Uie  system  strictly  connected,  must  be  reduced 
to  the  minimum.  Additionally,  since  the  algorithm  must  be  executed  every  frame  In  all  nodes,  it  must  be 
computationally  efficient,  and  must  allow  a  substantial  parallelism  in  inputs  and  outputs. 

-  time  response  the  basic  algorithm  must  have  the  minimum  time  response  to  a  signal  going  to  a  steady 
state  oondition  that  ensure  the  requirements  above  to  be  met.  It  must,  however,  be  easily  extendable  to 
filter  out  transients  shorter  than  an  arbitrary  durautxi 


lExiaFnPHCF'mEALaairmH 

The  proposed  algorithm  is  based  on  a  most  intuitive  oonsideratioa- 

If  the  System  is  oomposed  of  asynohronous  samplers  and  none  of  the  nodes  Knows  its  phase  relationship 
with  the  others,  the  single  node  is  not  able  to  conclude  about  an  agreement  among  all  nodes,  in  any 
selected  instant . 

If  however  we  consider  all  the  discrete  signals  coming  from  all  nodes  in  the  system  as  continuous  signals 
in  the  time  reference  of  a  single  node,  and  a  time  window  is  examined  with  a  sufficient  duration  (integer 
number  of  frames)  in  the  immediate  past,  every  node  is  able  to  compare  the  pattern  of  a  signal,  for  all 
nodes,  as  it  has  evolved  in  time. 

The  comparison  between  all  the  temporal  images  of  the  same  signal  as  seen  by  all  the  nodes  allows  to 
define  a  oonoept  of  “retrosipective  agreement",  that  means  if  an  agreement  cannot  be  sure  for  the  current 
sample,  it  may  be  possible  in  the  past,  if  the  patterns  in  the  past  are  close  enough  for  a  sufficient 
duration. 


The  algorithm  is  more  precisely  defined  as  follows 
Given  that 

1  All  nodes  are  sampling  all  inputs  and  execute  the  algorithm  every  frame  of  duration  t 

2  Each  node  oommurucates  to  all  nodes  in  the  system  (including  Itself)  the  value  of  the  direct  inputs  as 
sampled  by  it  within  a  time  «t  from  the  sampling  instant. 

3  Every  node  applies  the  algorithm  to  the  images  coming  from  the  other  nodes  and  from  Itself  (the 
latter  read  during  the  previous  frame  (see  note)). 

Then  the  result  is  calculated  as  follows 

«  Chosen  a  window  of  N  frames  if  the  patterns  received  from  ALL  nodes  show  a  common  level  of  the 
signal  in  at  least  H-l  consecutive  frames  then  the  result  is  made  equal  to  the  common  level. 

« If  none  of  the  two  logic  levels  satisfies  this  condltloa  the  logic  value  of  the  result  remains  equal 
to  the  OTie  at  the  previous  frame. 

NOTE :  This  last  clause  is  not  mandatory ,  since  a  difference  of  a  full  frame  is  inessential,  but  Is  useful  to 
maKe  the  following  discussion  simpler. 


Ihitm  the  clauses  1  and  2  we  can  say  that: 

a)  the  maxunum  duration  difference  fOr  any  of  the  transmitted  signals,  as  sampled  by  a  node  reading  the 
communication  data,  is  limited  to  one  frame,  source  to  source,  since  the  iso,  hronism  of  the  samplers 
limits  the  differences  only  to  phase  effects. 

b)  for  the  same  reasons,  the  maximum  difference,  in  terms  of  temporal  position  of  the  patterns.  Is  one 
frame. 
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The  aUoruiun  will  then  certainly  consKler  agreed  all  signals  with  a  steady  state  duration  >  (Il-1)»  t  , 
and  will  behave  as  an  absolute  filter  for  all  sijnals  with  steady  state  duration  <  (S-2)«  t. 

For  signals  with  a  steady  state  duration  within  the  Usuts  above, the  result  depends  on  the  phase  relation 
between  the  nodes,  but  yields  the  same  result  m  all  nodes,  independently,  with  a  difference  in  the  result 
phase  and  duration  between  any  two  nodes  muted  to  one  frame. 

The  full  asreement  required  by  the  aljorlthm  automatically  limits  the  pattern  steady-state  duration  to  the 
minimum  recognized  in  any  one  node 

Relative  to  the  signals  from  the  other  sources,  this  minimum  signal  is  either  in  phase  or  out  of  phase  by  one 
frame  and  anyway  always  in  the  same  sense  since  otherwise  the  worst  case  phase  shift  between  any  two  nodes 
would  be  2  frames,  contradicting  b). 


The  fact  that  the  patterns  have  to  be  recognized  within  a  time  window  that  is  one  frame  longer  than  the 
pattern  target  length  accommodates  for  both  duration  and  phase  differences ,  and  guarantees  that  the  event  of 
recognizing  the  agreanent  happens  (with  a  tolerance  of  one  frame  in  absolute  time)  in  all  nodes. 

The  differences  between  results  among  the  nodes  in  terms  of  resulting  pulse  durauon  and  phase  can  be  easily 
explained  m  an  absolute  time  reference. 

The  algorithm  has  in  fact  been  conceived  in  absolute  terms,  since  the  signal  relauons  are  more  evident  and 
remain  undistorted  by  the  sampling  in  a  particular  node. 

Let  us  consider  a  simple  example  consisting  of  4  completely  asynchronous  nodes,  C1X4  .  equally  distributed  , 
in  phase,  on  the  frame  t.  (Note  that  this  is  also  a  worst  case  for  synchronization). 

The  signals  retransautted  by  each  node  after  sampling  are  shown.  The  effect  of  sampling  is  evident,  stretching 
the  transmitted  signals  to  integer  multiples  of  t.  The  effect  of  phase  relations  is  also  evident,  both  on 
sampled  values  and  on  the  phase  of  retransmission 


In  continuous  terms,  it  appears  clear  how  the 
conditions  a)  and  b)  are  satisfied,  but  interes¬ 
ting  IS  the  virtual  signal  that  identifies  ,  in 
the  continuous  time,  the  full  agreement  between 
all  four  nodes  This  signal  is  the  temporal  inter¬ 
section  Of  the  signals  transmitted  by  all  nodes, 
and  as  such  is  unique  (in  the  continuous  time  ) 
and  IS  shorter  than  or  equal  to  any  of  the  tran¬ 
smitted  signals. 

If  this  signal  comprises  N  1  contiguous  sampling 
instants  for  any  node,  then  ALU  nodes  will  recog¬ 
nize  an  N-i  frames  pattern  in  all  signals  in  an  N- 
frame  window. 

In  fact  the  full  agreement  signal  starts  synchro¬ 
nously  with  the  sample  of  the  latest  node  ,  C4  , 
and  ,  to  contain  H  I  samples  for  it,  must  be  of 
duration  greater  than  (M  2)»  t  . 

But,  since  this  signal  is  the  temporal  intersec¬ 
tion  of  all  transmitted  signals,  this  means  that 
ALL  these  signals  have  a  duration  greater  than 
(N-2)«T  and  ,  since  the  signals  come  from 
sampling  their  duration  cannot  be  but  an  integer 
multiple  of  T,  and  so  must  be  at  least  (H- 

1)«T. 
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This  implies  that  at  least  H-l  contiguous  samples  are  present  in  all  the  patterns,  ana  ,  since  the  phase 
relation  is  limited  within  one  frame,  the  patterns  are  recognized  within  an  N  frame  window  in  ALL  nodes. 


On  the  contrary,  if  no  node  exists  for  which  the  full  agreement  signal  comprises  H-l  samples,  this  means  that 
at  least  for  one  node  the  transmitted  signal  is  shorter  than  H-l  frames,  le,  H -2  frames  or  less,  and  as  such 
no  node  will  be  able  to  recognize  an  H  1  frame  pattern  in  all  signals  within  the  window. 

This  technique  can  be  applied  to  both  logic  levels  independently,  and  for  H  >  3  the  mutual  exclusion  of 
agreement  on  the  two  levels  is  intrinsically  guaranteed,  and  so  no  ambiguities  are  possible. 

When  no  agreement  can  be  reached  on  either  leveL  ue.  during  fast  transitions  of  the  input,  or  in  response  to 
short  pulses,  the  algorithm  does  not  change  the  result  from  that  obtained  at  the  previous  frame.  This  decision 
may  be  considered  questionable,  but,  also  in  the  light  of  examples,  and  considering  that  in  a  sampled  data 
system  short  pulses  may  be  lost  due  to  its  nature  anyway,  seems  the  most  sensible  approach;  obviously,  the 
result  will  have  to  be  properly  initialized  at  startup,  and  the  signals  history  as  well,  to  obtain  a 
consistent  steady  state. 


The  following  logic  ncfworK  depicts  this  algorithm  for  N  : 
asynchrraious  nodes 


worKing  on  both  logic  levels,  with  4 


C1  Ca  C3  04 

3-STftGE  3-STflGE  3-STflGE  3-BTAGE 

FIFO  FIFO  FIFO  FIFO 


Kote  that  result  retention  in  case  of  no  agreement  has  heen  implemented  in  the  simplest  way,  tying  the  two 
agreement  signals  to  the  inputs  of  a  2/R  Flip  Flop,  since  the  two  agreement  signals  are  mutually  exclusive  and 
the  lacK  of  agreement  docs  not  alter  the  FUp-Flop  status,  its  output  Q  is  the  desired  result. 


FAULT  mamCBtlHElOH 


In  a  redundant  system,  it  is  common  practice  to  implement  complex  Bunt-m  Test  functions,  capable  to  isolate 
malfunctioning  nodes.  The  algorithm  can  be  extended  to  incorporate  a  maslung"  of  faulty  nodes'  data,  simply 
farcing  the  pattern  recognition  signals  for  such  nodes  to  their  active  state,  before  the  final  full  agreement 


The  agreement  is  then  dependent  only  on  the  signals  coming  from  the  worKlng  nodes,  since  the  agreement  of 
faulty  nodes  is  forced  unconditionally. 
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EHCTIEMmHANDmATIOMCaPAEajriES 

This  algorithm  can  be  extended  to  include  two  forms  of  error  detection  and  management;  faulty  node  data 
isolation  and  failsafe  operatioa 

:  Faulty  node  data  isolation. 

Apparently,  this  algorithm  ,  although  safe,  can  lead  to  a  stuck  system  only  because  a  single  failed  node 
remains  in  disagreement  with  the  others. 

This  oonditim,  however,  if  the  actual  input  discretes  are  not  in  continued  transition,  can  be  synchronized  as 
any  other  boolean  among  all  nodes,  or  at  least  among  all  working  nodes 

If  the  failure  of  a  node  is  such  to  deeply  alter  its  funcuons,  the  Built- in  Test  functions  will  isolate  that 
node  within  reasonable  time  If  instead  the  failure  is  more  subtle,  like  reading  a  single  discrete  m  a  stuck 
level  in  that  node,  the  agreement  among  all  nodes  (possibly  excluding  the  suspect  node!  on  the  fact  that  that 
node  has  been  in  disagreement  with  all  others  for  a  sufficient  period  of  time,  guarantees  that  the  set  of 
working  nodes  synchronously  decides  to  exclude  it,  and,  if  the  suspect  node  is  able  to  run  the  algorithm,  it 
Is  able  to  decide,  independently  and  synchronously,  to  shut  itself  down. 

;  Failsafe  operation. 

m  the  case  when  common  mode  errors  affect  all  nodes  of  one  type,  and  no  majority  agreement  is  reachable,  it 
Is  however  always  possible  to  reach  an  agreement  on  an  unresolved  situation  timed  out,  and  on  this  basis  to 
fbroe  the  result  to  a  failsafe  level  in  all  working  nodes  This  condition  must  latch  and  appropriate  messages 
must  be  sent  to  the  outside  world 


UFIUaCY  ffl  CASE  OF  HULTIFLE  PmSTE  MFUTS 

Since  the  algorithm  is  based  only  on  logical  operations  on  bits  stored  in  memory,  and  since  the  majority  of 
processing  units  is  able  to  operate  simultaneously  on  all  the  bits  in  an  arithmetic  unit's  register,  if  the 
history  of  signals  belonging  to  the  same  class,  le.  with  same  N- frame  window,  is  Kept  in  memory  with  all  bits 
“packed"  in  words ,  It  is  possible  to  apply  the  algorithm  on  the  entire  word,  obtaining  a  word  result  and 
reducing  execution  time  by  a  factor  equal  to  the  number  of  discretes  processed  in  parallel. 

The  masking  operations  may  be  done  in  parallel ,  as  well  as  fault  isolauon  and  reversion  to  failsafe  result, 


aKumis 

Asynchronous  redundant  architectures  have  long  been  regarded  as  risky,  in  terms  of  possible  artifacts 
occurring  due  to  their  nature  and  difficult  to  anticipate,  in  particular  in  management  of  boolean  entities. 
This  algorithm  Is  believed  to  relieve  much  of  these  concerns  and  to  allow  such  architectures  to  fully  exploit 
their  capabuities,  with  a  reasonable  price  in  terms  of  computational  loading. 

Asynchronous  loosely  coupled  architectures,  including  simpler  and  cheaper  hardware  configuration,  no  hardware 
weak  points,  independent  processing,  lower  chance  of  common  mode  failures  and  overall  benefits  in  terms  of 
cost  and  reliability  ,  can  be  employed  without  the  deterrent  of  extensive  communication  needs  to  solve 
synchronization  issues 
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ABSTRACT 

This  paper  defiaes  the  performance  parameters  for  distributed  real-time  control  systems  and  describes  the  differences  in 
requirements  between  these  and  the  other  major  category  of  distributed  real-time  systems:  resource  sharing.  Examples  of 
explicit  values  of  the  performance  parameters  are  given  for  some  applications.  Finally,  an  evaluation  is  made  of  the  applicability 
of  existing  and  emerging  communications  standanis  to  real-time  distributed  control  systems. 

CATEGORIES  OF  REAL-TIME  SYSTEMS 

There  are  two  major  categories  of  real-time  distributed  systems:  control  and  resource  sharing  systems.  The  major 
difference  is  that  control  systems  have  hard  deadlines  to  meet  and  resource  sharing  systems  do  not.  A  hard  deadline  means  that  a 
late  result  is  equal  to  system  failure.  The  communication  requirements  for  these  two  types  of  applications  are  vastly  different. 

Resource  sharing  systems  are  general  purpose  information  processing  applications  sharing  distributed  services  and 
resources.  These  shared  services  can  be  physical  resources  such  as  data  bases,  processors,  and  printers,  or  they  can  be  shared 
information  possibly,  but  not  necessarily,  generated  in  leal-time  such  as  electronic  mail,  voice,  telemetry,  or  graphics.  Resource 
sharing  applications  may  involve  large  amounts  of  data,  and  sometimes  they  are  referr^  to  as  Information  or  Data  Processing 
Systems. 

These  systems  are  *open*;  that  is,  they  are  not  predefined,  and  they  include  many  different  types  of  resources.  In  addition  to 
reliability,  the  main  requirements  driver  is  commonality  between  heterogeneous  resources.  Real-time  for  these  applications 
means  "re^  fast'  and  can,  as  a  rule,  be  measured  in  terms  of  the  level  of  'human  inconvenience';  there  are  no  firm  deadlines  to 
meet,  and  there  is  no  severe  penalty  for  an  occasional  long  response. 

Resource  sharing  systems  are  not  further  addressed  in  this  paper;  the  applications  are  well  understood  and  the  technology 
exists.  Their  communication  requirements  can  be  met  by  the  standards  intended  and  developed  for  these  applications,  the  OSl 
(Open  System  Interconnect)  Reference  Model  and  1EEE-802.X  or  the  emerging  ANSI  FDDl,  for  example. 

Control  systems  differ  in  communication  requirements  significantly  from  those  described  above,  and  the  technologies 
required  are  nonexistent  or  at  the  'cutting  edge'  stage.  Industrial  control  applications  are  usually  referred  to  as  process  control 
systems. 

These  real-time  process  and  control  systems  are  not  'open';  their  applications  are  specific  and  their  resources  dedicated  to 
the  application.  They  are  tightly  coupled  in  time  and  can  be  characterize  by  the  fact  that  they  have  firm  deadlines  to  meet,  and 
failure  to  meet  the  deadline  is  critical  and  possibly  life  threatening.  Their  applications  are  often  so  large  or  complex  that  they 
require  more  than  one  computational  resource  concurrently:  the  distribution  of  the  task  itself. 

These  control  systems  are  complete  entities  with  defined  allocation  of  resources  and  predictable  communications.  They  are 
usually  of  a  limited  geographical  distribution  such  as  a  military  platform  or  a  chemical  processing  plant,  but  this  may  not 
necessarily  be  true.  SDI,  for  instant,  will  fall  in  this  category. 

Control  systems  do  not  require  connectivity  to  a  large  number  of  undefined  different  manufacturers' equipment;  two-three 
to  a  dozen  may  be  enough  for  any  one  application.  The  connectivity  can  be  supported  by  one  (or  a  couple)  physical  medium  and 
a  limited  number  of  protocols.  Of  course,  these  applications  do  require  interoperability  between  similar  equipment  from 
different  vendors  for  cost  effectiveness. 

Distribution  of  a  task  over  several  computational  resources  also  requires  the  distribution  of  execution  control  to  said 
resources.  The  requirements  of  this  distribution  of  execution  control  cannot  be  satisfied  with  the  statistical  quality  criteria  of  the 
communication  standards  mentioned  above.  Deterministic  low  latency  quality  control  is  required  for  time  distribution,  task 
synchronization,  and  sensor/effector  data  integrity. 

CONTROL  SYSTEMS  PERFORMANCE  PARAMETERS 

Real-time  for  control  systems  can  be  quantified.  Performance  parameters  include  the  control  loop,  resolution,  and  the 
distribution  of  control,  where  the  distribution  of  control  can  further  be  broken  down  into  latency,  periodic  traffic  jitter,  order, 
and  accuracy.  Degree  of  fault  tolerance  required  and  automation  are  system  level  parameters  which  impact  the  design  and 
performance  of  the  communications. 

CONTROL  LOOP 

The  process  control  term  for  control  loop  is  fundamental  frequency.  It  is  a  measure  of  the  degree  of  real-time.  It  is  the  total 
time  allowed  for  a  specific  task  measured  from  the  input  of  a  sensor  to  the  completion  of  the  reaction  at  an  affector.  Most 
control  systems  have  more  than  one  control  loop:  hierarchies  of  control  loops. 
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Examples  of  explicit  requirements  for  the  control  loop  for  some  different  applications  are  as  follows. 

In  the  recent  Stark  incident  in  the  Persian  Gulf,  the  control  loop  was  2  minutes.  That  was  the  time  the  Stark  had  to  intercept 
and  dmroy  the  missile  starting  from  the  sensors  detecting  the  release. 

For  the  Space  Shuttle  Mission  Operational  System  (MOS),  the  ground-based  mission  manager,  the  control  loop  is  I  /  2 
second. 

For  avionic  simulators,  the  control  loop  is  90  or  150  ms,  depending  on  whether  the  aircraft  is  a  tactical  fighter  or  a 
helicopter  with  nap-of-the-earth  capability  or  a  transport  aircraft.  This  delay  is  the  interval  between  the  pilot  (in  th;  rirr’Mated 
cockpit)  changing  aircraft  controls  and  seeing  an  indication  of  the  change  on  the  control  panel. 

For  oil  refineries,  there  are  a  few  I  second  control  loops,  but  most  loops  are  between  8  and  64  seconds. 

The  New  York  city  Traffic  Control  system  has  local  1  second  loops  changing  green/red  light  allocation  at  major 
intersections  as  measur^  starting  from  the  seizor  in  the  street.  The  loop  to  change  traffic  patterns  for  all  of  the  city  is  10 
minutes. 

A  juggling  robot  being  designed  at  IBM's  Research  division  in  Yorktown  has  control  loops  of  JOO  ms  and  300  ms.  The  300 
ms  loop  is  from  throw  to  catch  of  the  puck  by  the  mechanical  hands.  The  100  ms  loop  is  from  the  decision  to  move  the  receiving 
hand  to  the  actual  catch. 

For  tactical  fighters,  the  control  loop  (one  of  many)  is  10  ms. 

RESOLUTION 

The  process  control  term  for  resolution  is  processing  frequency.  It  is  the  frequency  of  repetition  of  cither  computation, 
sensor  sampling,  or  actuator/effector  reactions.  It  is  a  measure  of  system  granularity,  and  most  control  systems  are  hybrids  with 
various  resolutions  in  different  functional  areas  of  the  system.  For  instance,  sensor  sampling  is  often  at  a  higher  resolution  than 
the  main  computational  resolution  with  filtering  and  preprocessing  of  the  sensor  data. 

Resolution  is  sometimes  measured  in  time  but  most  often  in  Hz  (or  cycles  per  unit  of  time).  Examples  of  explicit  resolution 
requirements  for  some  control  system  applications  are  as  follows. 

The  Shuttle  Mission  Operational  System  has  resolutions  of  10, 2,  and  1  Hz  in  different  functional  areas  of  the  system. 

The  New  York  city  traffic  control  system  samples  sensors  in  the  street  at  60  Hz,  while  the  update  rate  for  the  total  system  is 
every  10  minutes.  Local  traffic  light  changes  arc  more  frequent.  The  60  Hz  resolution  may  seem  high,  but  it  allows  the  speed  of 
the  cars  to  be  measured,  thus  directly  indicating  the  system  operational  effectiveness. 

The  resolution  of  the  juggling  robot  is  60  Hz. 

Avionic  simulators  at  present  operate  at  5,  and  60  Hz.  Some  are  hybrids  with  aircraft  sensor  data  updated  at  20  Hz  and 
the  out-the-window  displays  at  60  Hz.  The  sensor  data  resolution  requirements  are  gated  by  the  resolution  of  the  aircraft  system 
being  simulated  and  those  of  the  out-the-window  displays  by  human  perception. 

For  oil  refineries,  the  processing  frequency  is  3  Hz  but  may  involve  the  multiplexing  of  several  hundred  data  points  per 
second.  The  resolution  is  limited  by  the  recovery  time  of  the  flying  capacitor  analog  input  multiplexor. 

The  resolution  requirement  for  tactical  fighters  in  development  is  500  Hz.  Advanced  radar  applications  presently  have  a 
resolution  of  250  Hz  and  IFF  (Identification  Friend  or  Foe),  200  Hz.  There  also  arc  classified  applications  with  resolution 
requirements  of  SO  kHz. 

CONTROL  DISTRIBUTION:  LATENCY 

Latency  here  is  defined  as  the  task-to-task  delay,  which  includes  the  communication  protocols.  It  may  be  a  function  of  the 
number  of  stages  in  the  processing  pipeline  and  is  dependent  on  the  system  design.  For  data-driven  applications,  it  is  from  the 
completion  of  one  task  to  the  initiation  of  the  next. 

Latency  is  measured  in  time  and  varies  with  the  type  of  communication  service  required  such  as  acknowledged,  connection 
oriented,  etc..  Examples  of  latency  requirements  for  some  applications  are  as  follows. 

An  avionic  simulation  with  90  ms  control  loop  can  be  implemented  with  a  task-to-task  delay  of  5  ms.  The  juggling  robot 
requires  I  to  2  ms  latency  and  the  classified  application  4^s.  A  system  designed  to  control  a  nuclear  power  plant  in  Belgium  has 
1000  data  points,  all  of  which  have  to  be  delivered  in  less  than  10  ms,  and  the  tactical  figh  ter  has  delay  requirements  for  certain 
messages  of  1  ms. 

CONTROL  DISTRIBUTION;  PERIODIC  TRAFFIC  JITTER 

The  process  control  term  for  periodic  traffic  jitter  is  scan  frequency  variability.  It  defines  the  degree  of  precision  for  time 
distribution,  task  synchronization,  and  sensor/efiector  data  integrity.  Allowable  jitter  in  periodic  traffic  as  a  rule  is  a  function  of 
the  resolution;  the  higher  the  resolution  the  smaller  the  allowable  jitter. 

Periodic  traffic  jitter  is  measured  in  time.  Examples  of  periodic  traffic  jitter  for  some  applications  are  as  follows. 

For  the  60  Hz  avionic  simulation,  a  periodic  traffic  jitter  of  0.5  ms  is  acceptable.  For  advanced  radar  applications,  50^  is 
acceptable.  For  the  French  tactical  fighter,  200^  jitter  is  deemed  acceptable,  while  the  British  fighter  design  requirement  is  50 


I 
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AK.  The  classify  application  needs  periodic  traffic  jitter  not  to  exceed  I S  to  20 /js.  The  Architectural  Control  E>ocuinent  for  the 
U.S.  Space  Station  calls  out  a  requirement  for  time  distribution  to  an  accuracy  of  10 1». 

CONTROL  DISTRIBUTION:  ORDER 

For  process  control  systems,  the  sister  term  is  sequence  of  events  or  SOE.  For  instance,  during  process  upsets,  order  can  be 
extremely  important  for  many  petrochemical  processes.  During  t)M  process  upset,  many  alarm  conditions  may  occur,  and  it  is 
necessary  to  know  their  order  to  correct  the  cause  rather  than  one  of  the  symptoms. 

For  data-driven  distributed  applications,  guaranteed  message  order  of  arrival  is  essential  for  some  message  categories. 
Other  distributed  applications  require  guaranteed  message  order  of  arrival  during  degraded  system  states  for  anomaly  handling 
when  making  best-effort  decisions  based  on  partial  data  sets. 

CONTROL  DISTRnUTION:  ACCURACY 

Accurs^y  is  the  differential  reception  time.  It  is  the  delta  in  time  between  reception  at  the  first  and  last  destinations  of  a 
message  transmitted  simultaneously  to  more  than  one  destination.  For  a  physical  broadcast  medium,  it  is  the  medium 
propagation  delay  between  destinations.  For  token  passing  rings,  it  is  a  function  of  the  station  delay  and  the  mtJium 
propagation  delay. 

Fault-tolerance 

Fault-tolerance  is  a  major  requirements  driver  for  control  systems.  Most  control  applications  require  uninterrupted 
operational  performance  with  extremely  short  or  no  ‘hiccup*;  that  is,  instantaneous  fault  detection,  isolation,  and  reconfigura¬ 
tion.  Other  control  applications  require  a  graceful  degradation  after  a  fault  with  continued  operation  in  degraded  mode. 

The  containment  of  the  failures  is  also  essential  for  process  control  systems;  they  must  not  ripple  through  the  system.  The 
process  control  term  is  scale  of  failure. 

The  petrochemical  industry  has  been  at  the  forefront  of  control  technology  because  hydrocarbon  processes  tend  to  run 
away  and  self-destruct.  The  primary  concern  has  been  for  safety  for  the  equipment  and  human  life.  Production  rates  and 
product  consistency  and  quality  have  been  of  secondary  importance.  This  is  reflected  in  the  computer  programming  for  these 
systems;  about  10%  of  the  effort  (lines  of  code)  is  concerned  with  actual  control  functions  and  the  remaining  90%  with  control 
integrity. 

For  military  applications,  availability  and  performance  are  of  paramount  importance.  From  Chernobyl  we  have  recent 
knowledge  of  what  scale  of  failure  can  mean  for  a  process  control  system,  but  it  is  difticult  to  envision  the  consequences  of  a 
‘runaway*  or  incorrectly  operating  military  system.  Therefore,  the  requirements  of  these  distributed  real-time  control  applica¬ 
tions  also  include  a  high  degree  of  fault-tolerance  for  equipment  failures.  This  impacts  all  layers  of  the  communications 
protocol,  and  it  is  a  major  difference  from  resource  sharing  systems. 

APPLICABILITY  OF  COMMUNICATION  STANDARDS  TO  CONTROL  SYSTEMS 

LOWER  LAYER  PROTOCOLS 

After  an  independent  evaluation  board  unanimously  agreed  that  only  a  token  passing  ring  could  meet  all  the  requirements 
in  the  HART  Document  (1),  the  Avionic  Systems  Committee  of  the  Society  of  Automotive  Engineers  (SAE-AS2)  examined 
existing  and  emerging  token  passing  ring  technology  for  applicability  to  distributed  control  systems. 

The  IEEE  802.5  could  not  meet  the  throughput  requirements,  and  increasing  the  clock  rate  was  not  a  viable  solution. 
FDDl,  an  emerging  ANSI  standard,  did  meet  the  throu^put  requirements,  but  with  a  severe  bandwidth  penalty  if  access 
performance  is  required.  Simulation  data  has  shown,  for  instance,  that  for  a  guaranteed  required  access  of  1  ms,  which  does  not 
meet  the  explicit  requirements  documented  in  this  paper,  only  20%  of  the  FDDl  bandwidth  could  be  utilized  (2). 

It  was  also  determined  that  the  FDDl  access  method  was  ill-suited  for  the  distribution  of  control.  Us  priority  mechanism 
cannot  guarantee  the  order  of  arrival;  higher  priority  messages  do  not  necessarily  get  transmitted  before  these  of  lower  priority. 
And  for  stations  with  messages  pending  of  the  same  priority,  access  is  not  a  fair  round  robin  hut  dependent  on  the  physical 
location  of  the  station  (3). 

A  detailed  comparison  of  the  two  protocols  (FDDl  and  HSRB)  was  performed  for  space  applications.  This  study  included 
simulation  data  of  the  two  in  the  scenario  of  the  tKnchmark  tests  specified  in  the  HART  document.  The  results  show^  that  the 
two  performed  about  equally  when  all  messages  were  of  the  same  priority,  but  the  FDDl  timers  could  not  be  set  to  support  the 
priority  separation. 

After  the  SAE  committee  established  that  neither  the  FDDl  nor  the  IEEE  802.5  prott  ^1  could  be  modified  to  meet  the 
requirements  set  forth  in  the  HART  document,  the  committee  set  out  to  develop  a  token  passing  ring  standard  specifically 
intended  to  address  distributed  fault-tolerant  real-time  control  applications.  The  High  Speed  Ring  Bus  (HSRB)  was  released  in 
April  of  1 987  as  Draft  SAE  Standard  AS4074.2  (3).  Many  Department  of  Defense  standards  are  generated  by  this  international 
b^y. 

The  HSRB  media  access  protocol  supports  low,  fully  deterministic  message  latency  through  message  based  priority 
reservation.  Its  priority  operation  can  guarantee  m^sige  older  of  arrival.  Enforcement  of  the  priority  operation  on  all  messages 
is  a  system  design  option  that  may  be  dynamically  selected  at  a  small  bandwidth  penalty.  An  optional  Multiple  Short  Message 
protocol  bypassing  the  priority  operation  allows  the  insertion  of  up  to  16  messages  shorter  than  the  ring  latency  before  priority 
again  is  enforced. 
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Periodic  traffic  jitter  for  the  HSRB  can  be  cootroUed  by  priority  assignment,  and  it  is  a  function  of  the  maximum  allowed 
message  length  in  the  system  design.  For  instance,  if  highest  priority  is  allocated  to  the  time  distribution  task,  different  levels  of 
precision  can  be  achieved  by  controlling  the  message  length,  as  illustrated  in  Table  1 . 


Table  1.  HSRB  Periodic  Traffic  Jitter 


Max  Msg  Length 

Max  Synchronization  Jitter 

Number  of  Bytes 

Priority  Order  Selected  (ms) 

Priority  Order  Not  Selected  (ms) 

2048 

0.40 

0.45 

1024 

0.20 

0.35 

512 

0.10 

0.30 

32 

0.01 

0.25 

The  second  column  is  when  priority  order  is  not  selected  and  multiple  short  messages  are  allowed.  Jitter  for  a  second 
periodic  message  assigned  next  highest  priority  will  add  roughly  50%  to  those  values. 

To  meet  the  fault-tolerance  requirements  of  the  intended  applications,  the  HSRB  protocol  with  dual  counterrotating  rings 
supports  high  speed  automatic  physical  reconfiguration.  This  means  stations  can  be  inserted  or  removed  or  a  broken  fiber 
bypassed  in  less  than  a  millisecond.  This  is  done  in  hardware  and  does  not  require  any  software  negotiation. 

HSRB  supports  two  addressing  modes:  physical  and  logical.  The  logical  mode  provides  for  the  addressing  of  tasks  rather 
than  hardware  stations.  This  way,  a  task  (or  its  station)  communicating  with  another  task  need  not  be  aware  of  what  processor  it 
is  transmitting  to,  thus  eliminating  the  need  for  routing  directories  and  some  of  the  time  consuming  processing  traditionally 
done  by  communication  protocols. 

Logical  addressing  also  provides  for  software  containment  of  failures.  If  a  processor  goes  down,  for  instance,  only  the 
processor  replacing  it  is  affected.  Other  processors  containing  tasks  that  were  communicating  with  tasks  in  the  failed  processor 
need  not  be  notified  through  loading  of  new  configuration  ubles  since  the  physical  locations  of  other  tasks  are  transparent.  This 
way.  the  HSRB  protocol  allows  for  the  containment  of  failures. 

Automation  was  also  a  requirements  driver  for  the  HSRB  logical  addressing.  Artificial  Intelligence  tasks  for  the  HSRB 
intended  applications  require  rapid  parallel  searches  of  distributed  dynamically  updated  data  bases.  Logical  addressing  on  the 
physical  medium  provides  this  capability. 

UPPER  LAYER  PROTOCOLS 

Standards  do  not  yet  exist  for  the  upper  layers  of  the  communications  protocol  required  to  support  distributed  real-time 
fault-tolerant  control  applications. 

OSI,  the  only  widely  accepted  standard  for  upper  layer  protocols,  is  much  too  slow.  For  instance,  performance  measure¬ 
ments  taken  at  the  National  Bureau  of  Standards'  Network  Laboratory  indicate  best-case,  end-to-end  delays  of  33  ms  (S), 
excluding  the  uppermost  three  layers. 

Faced  with  the  immediate  need  for  low  overhead  protocols  several  years  ago,  IBM's  Federal  Systems  Division  embarked 
on  the  development  of  a  next-generation  communications  architecture  for  its  Advanced  Systems  Development  Laboratory 
(ASDL). 

Performance  measurements  on  the  lowest  layer  of  the  three  layer  ASDL  archilcciuic  using  Ptotcon's  80  Mb/s  token 
passing  ring  indicate  the  feasibility  of  achieving  the  end-to-end  delays  required  for  real-time  control  systems. 

In  addition  to  being  too  slow,  the  OSI  Reference  Model  can  not  be  adapted  to  distribute  control  in  the  form  of  time  or  task 
synchronization.  Many  required  services  do  not  presently  exist,  even  though  some  additions  are  being  worked  into  the  model, 
and  the  OSI  allocation  of  existing  functions  to  specific  layer  is  not  optimized  for  real-time  control  applications. 

Some  of  the  OSI  deficiencies  include  acknowledged  datagrams,  predefined  connectic  n-oriented  service,  nonacknowledged 
connection-oriented  service,  concentration  capabilities,  and  automatic  invocation.  Required  multicast /broadcast  is  presently 
not  included  in  the  OSI  standard  but  it  is  being  worked. 

Another  capability  required  for  the  SAE  HSRB  intended  applications  that  is  lacking  is  refresh.  Kalman  filters,  for 
instance,  may  need  up  to  five  sets  of  the  most  current  periodic  data  points  with  automatic  ovei  writing  of  the  oldest  data,  other 
cyclic  applications  may  need  two  or  throe  dau  points  with  the  oldest  set  refreshed  at  a  periodic  rate. 

However,  some  of  OSI  developed  methodology  docs  apply  to  control  systems.  The  philosophy  and  structure  and  many  of 
the  goals  do;  only  the  intended  applications  are  different.  Upper  layer  protocols  under  development  for  real-time  control 
systems  take  advantage  of  OSI  methodology,  including  the  partitioning  into  layers  of  functional  capability,  peer  entity 
associations,  and  the  layer  interface  concepts  of  service  primitives  and  service  access  points. 
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As  with  the  OSl  Reference  Model,  the  Europeans  have  been  on  the  forefront  of  this  development,  recognizing  several  years 
ago  that  there  was  a  need  to  develop  communication  standards  specifically  for  distributed  control  applications.  A  proposal  on 
the  applicability  of  the  OSI  model  to  shipboard  systems  was  presented  by  an  Italian  delegate  at  a  NATO  meeting  as  early  as 
1973,  and  the  French  government  is  presently  supporting  the  defmition  of  a  real-time  model  called  the  GAM-T-10? 

Within  the  United  States,  the  SAE-AS2  Communication  System  Requirements  Subcommittee  is  the  major  standards 
forum  for  these  applications.  Driven  primarily  by  the  desire  for  interoperability  of  a  strong  combined  defense,  the  S  AE  is  also 
the  focal  point  for  NATO  country  technology  exchange. 
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SUMMARY 

This  paper  begins  by  considering  som  of  the  problems  that  have  arisen  In  Che  application  of 
traditional  reliability  Mthoda  to  fault'-tolerant  syste»s,  particularly  with  the  videly^used  fault 
tree  approach.  The  application  of  the  Markov  atate-flow  equation  to  reliability  analysis  Is  then 
considered  and  It  is  shown  how  nany  of  the  aforeaantloned  problems  disappear  with  this  approach  and  bow 
the  basic  eqtiatlon  can  be  ■anlpulated  to  include  repair  pollclesi  discrete  events,  and  to  calculate 
aysten  reliability.  Then  the  lesucs  are  taken  on  to  the  next  step  by  considering  how  to  set  up  a 
reliability  model  from  system  design  information  In  such  a  way  as  to  ensure  Che  Markov  states  and 
transitions  are  correct  and  so  as  ensure  that  Che  reliability  analysis  gives  an  upper  bound  for  system 
failure.  The  concept  of  formulation  of  design  Information  and  automatic  generation  of  a  reliability 
model  for  any  given  aystem  is  explained  and  an  example  analysis  given  based  on  a  typical  jet  engine 
control  system. 

1  INTRODUCTION 

Traditionally  reliability  predictions  for  Industrial  systems  are  widely  done  using  the  fault  tree 
method  of  approach.  Henley  and  Kumamoto  (reference  1)  trace  the  development  of  fault  trees  from 
their  hazy  origins  out  of  the  previously  erroneous  "strong  as  the  weakest  member"  philosophy. 

Fault  trees  have  been  widely  taken  on  board  throughout  Industrial  engineering  as  the  standard 
method  of  representing  and  calculating  system  reliability,  to  the  extent  that  the  method  is 
regarded  as  the  natural  one  In  the  minds  of  moat  engineers,  and  any  tendencies  of  the  method 
cowards  a  residue  of  errors  and  omissions  and  inaccuracies  become  either  glossed  over  or  attacked 
on  an  "ad  hoc"  basis.  However,  when  a  system  Is  being  analysed  which  substantially  breaches  the 
llmlCaClona  of  the  traditional  methods  so  that  the  end  product  becomes  one  In  which  the  errors, 
omissions,  and  Inaccuracies  become  potentially  serious  and  the  final  reliability  prediction 
cannot  be  Justified  to  any  great  extent  or  only  with  great  difficulty  then  a  new  approach  Is 
required.  The  Harkov  Probability  Analysis  (MPA)  method  has  Its  roots  In  an  snclsnt  tschnlque  but 
la  gaining  credibility  as  an  alCernstlve  method  for  system  reliability  prediction.  The 
Reliability  Model  Generation  (RMC)  method  goes  further  and  overcomes  the  problems  not  addressed 
by  the  Markov  method. 

2  FAULT  TREES  AND  PROBLEMS 

Henley  and  Kumamoto  (reference  1)  show  that  Che  credibility  of  the  "strong  as  the  weakest  link" 
philosophy  suffered  In  the  German  rocket  prograxme  of  the  1940'b  and  the  idea  began  to  emerge 
that  tiie  system  reliability  could  be  better  estimated  by  considering  the  effects  of  random 
failures  In  all  the  components.  For  many  years  after  that  the  systems  being  enslysed  consisted 
largely  of  aon-redundanC  non-fault-toleraut  deslgna.  The  fault  trees  for  such  systems  consisted 
largely  of  a  collection  of  base  events  feeding  into  a  single  'OR*  gate  at  the  top,  the  reason  for 
such  8iaq>llclty  being  inherent  In  the  nature  of  the  available  hardware  of  the  time,  and  ths 
capability  of  carrying  redundant  parts  in  any  given  system.  Such  redundancy  and  back-up  systems 
as  did  exist  tended  to  be  fairly  simple  and  usually  bullt-on  afterwards.  Whilst  it  is  stretching 
Che  point  a  bit  to  say  this,  it  was  almost  a  case  of  designing  a  system  without  redundancy  and 
then  If  a  back-up  was  needed  It  would  be  by  means  of  another  coi^lete  system.  Reliability 
predictions  for  such  systems  could  be  obtained  by  considering  the  rate  of  occurrence  of  random 
failures  in  each  event  that  feeds  into  the  top  'OR*  gate  and  doing  the  arithmetic  accordingly. 

As  time  vent  by  and  technology  moved  on,  particularly  with  the  advent  into  coason  use  of 
electronics  of  first  analogue  and  then  digital  type,  systems  could  be  designed  with  redundancy  ** 
that  vary  much  smaller,  and  in  time  not-so-expcnalve,  parts  could  be  bsckad-up  In  a  way  that 
enables  many  faults  to  be  tolerated  vlcbin  the  system.  Fault  traea  for  such  ayatama  began  to 
grow  alarmingly  and  throw  up  new  problems  to  be  overcome  In  order  to  obtain  the  reliability 
prediction  with  any  degree  of  confidence. 

The  first  such  problem  concerns  "exposure"  end  "snap-shot"  times.  System  reliability  is 
traditionally  exprasaed  la  terms  of  rate  of  occurrence  per  hour  or  In  some  other  similar  units. 

For  non-redundsnt  systems  when  the  overall  reliability  is  largely  made  up  of  single  random 
events  then  the  calculation  Is  relatively  straightforward.  However,  when  combinatlona  of  events 
are  considered  then  the  calculations  sra  based  upon  probebllltles  of  the  combined  events  occurring 
together  or  in  sequence.  In  order  to  carry  out  such  eslculstlons  the  traditional  msthod  is  to 
assign  to  each  contributing  random  event  an  "exposure"  time  representing  e  typical  period  over 
which  the  system  is  exposed  to  that  fault  sod  dividing  tha  top  event  probability  by  the 
appropriate  "anap-shot"  time  Inherent  in  tha  specified  exposure  times.  Thus  for  fault-tolerant 
systems  theta  Is  always  aoms  kind  of  eias  factor  appearing  In  the  system  reliability  eslculatlon. 
The  end  product  la  a  fault  tree  and  corresponding  calculation  which  assumes  a  snap-shot  period 
within  which  tha  probability  of  syst^  failure  la  considered.  The  question  arises  as  to  what 
snap-shot  and  exposure  times  should  be  ueed  In  the  cslculatlonT  This  question  is  particularly 
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p^rclMnt  to  donsBC  foulto  or  foulto  lAlch  mx*  not  ropAlrod  except  follovlng  etiocher  fellure. 

The  14e4l  snep-ehot  period  to  teke  le  the  tlac  et  vhlcb  it  1b  k&om  that  the  sy«te«  vill  be 
cleared  of  all  exlaties  faulte.  Sue  it  ie  often  aore  ■eaclngfMl  to  take  the  enap^ehot  period  as 
covering  a  particular  eyatea  **rua**  which  then  raleee  the  leeue  of  netting  exposure  tinea  of 
faulte  that  could  already  exist  in  the  systea  before  the  "run**  conaenceSf  in  such  a  %ray  that  the 
enap>ehot  period  could  be  considered  typical. 

The  second  problea  la  that  of  significance  of  faults.  This  Issue  aftecta  the  Inclusion  or 
exclusion  of  certain  faults  in  the  fault  tree  depending  on  the  relative  failure  rates  and  exposure 
tines*  and  also  affects  the  order  of  accuracy  of  the  reliability  calculation.  The  reliability 
engineer  often  haa  to  naka  a  judgenant  aa  to  what  to  Include  In  a  fault  tree  analysis  and  ths 
tenptstlon  Is  there  to  go  for  a  trade-off  of  calculation  coaplexity  versus  calculation  accuracy. 
But,  particularly  where  doment  faults  are  concerned*  this  can  lead  to  oalsalons  chat  are 
potentially  significant.  In  theory  everything  should  be  considered  but  In  practice  this  Is  not 
so. 


The  third  problen  concerns  fault  ordering  which  addresses  the  issue  of  whether  any  particular 
fault  haa  to  occur  before  another  in  order  to  cause  total  systan  failure.  This  tends  to  occur 
quite  frequently  lu  aysteas  where  there  are  back-up  possibilities*  particularly  where  the 
detection  (and  hence  accosModatlon)  of  a  given  fault  could  ha  affected  by  previously  occurring 
faults.  Consider  s  systea  with  s  fault  tree  represented  by  one  top  *0R*  gate  and  a  lower  'AND* 
gate  In  one  branch.  If  the  required  order  of  occurrence  of  faults  In  even  such  a  sl^le  system 
la  altered  this  can  cause  non-slaple  changes  to  the  eystea  reliability  calculation.  When 
conaidarlng  order  of  repair  of  faults  also  the  debates  that  can  arise  concerning  factors  or  other 
such  cocslderstione  in  reliability  analysis  are  apparently  llaitleast 

The  fourth  problea  la  that  of  fault-dependence  which  arises  out  of  the  poeslblllcy  of  Including 
Che  ssae  fault  in  different  branches  of  the  fault  tree  In  a  way  that  leads  to  errors  in  the 
calculation.  It  is  difficult  for  all  but  siapla  aysteas  to  write  down  the  fault  tree  exactly 
corresponding  to  the  correct  Boolean  expresalon  for  failure  coablnatlone  without  the  possibility 
of  oaittlng  something  or  including  the  eaae  thing  twice.  For  instance*  if  the  same  fault  can 
occur  In  2  branches  leading  to  an  'AND*  gate  then  although  the  Boolean  logic  aay  be  correct  the 
rellebility  calculation  la  in  danger  of  asexialng  2  faults  must  occur  where  only  one  actually 
happens « 

The  fifth  problen  Is  chat  of  fsult-propogatlon  which  describes  the  possibility  that  a  fault  In  a 
aystcB  may  cause  other  parte  of  the  syetea  to  fall  also.  For  Instance,  If  a  dual-redundant 
systea  Is  powered  electricslly  froa  a  single  power  supply  then  failure  of  that  power  supply  would 
cause  the  failure  of  all  the  dual-redundant  parte  also  and  lead  to  system  failure.  These  effects 
can  often  be  staple*  but  also  can  often  be  complex  and  lead  to  errors  or  oalsslons  in  the 
anslysls. 

The  sixth  problea  chat  can  arise  Is  Che  fuadaaental  one  of  deteialnlng  operational  requirements 
of  the  syetea.  This  Is  conceptually  the  reverse  of  the  systea  failure  requireaents  l.e.  a 
staCeaenC  of  that  which  is  needed  to  aalntaln  systea  operation.  This  le  usually  the  way  round 
that  a  systea  le  designed  and  so  Is  more  easily  linked  to  the  systea  design  sssuapClons.  Also 
operational  requirements  tend  to  Include  an  eleaenC  of  "preference"  whereby  Che  redundancy  Is  not 
as  staple  as  saying  "either  this  or  that"  but  instesd  defines  which  sec  of  systea  partr  are  in 
the  active  control  loop  at  any  given  moment  depending  on  what  faults  have  already  occurred.  This 
notion  then  requires  that  faults  In  the  active  control  sec  (as  It  is  defined  at  the  time  of  Che 
fault  occurrence)  will  need  to  be  treated  aore  seriously  in  the  analysis  than  faults  In  the 
currently  redundant  parts.  Traditional  reliability  analysis  methods  do  not  have  a  ready  made  way 
of  picking  this  up  and  can  overlook  its  iapllcations  particularly  where  the  active  control  set 
bae  a  fair  degree  of  flexibility. 

The  seventh  problea  le  concerned  with  Che  various  accomodation  methods  that  can  exist  within  a 
systea  so  cnsbllng  It  to  reconfigure  follovlng  the  detection  of  a  fault  within  it.  This  may 
include  hardware  accoaaodatlon  whereby  a  like  or  similar  part  is  used  in  place  of  the  failed 
part*  or  software  accomodation  i^ereby  a  dlgltsl-based  systea  will  opt  to  perform  Its 
calculations  based  on  Che  availability  of  an  alternative  set  of  hardware  functions.  This  latter 
type  of  accoaaodatlon  Is  increasing  In  availability  and  flexibility  In  current  industrial 
aysteas. 

The  eighth  problea  concerns  the  ^^cectsbiUty  sac  detection  of  faults.  This  Issue  is  linked  In 
with  the  operational  requireaenta  In  that  an  undetected  fault  needs  to  be  treated  aore  seriously 
than  a  detected  fault.  For  a  start*  where  an  undetected  fault  can  lie  dormant  in  the  system  for 
a  long  period  of  clas*  then  there  la  s  steadily  Increasing  possibility  of  a  real  system  problem 
due  to  that  undetected  fault  being  Included  In  the  active  control  set.  It  goes  without  saying 
that  s  fault  cannot  be  accomodated  unless  it  Is  some  way  detected  within  Che  systea  and  cannot 
be  repaired  unless  It  Is  some  way  known  to  the  operator.  Thus  s 'stea  reliability  i  clouded  by 
the  at-the-t  .  e  definition  of  the  active  control  set  parts  and  the  existence  of  and  operation  of 
a  detection  method  and  by  the  accomodation  If  detected. 

Ths  ninth  such  problea  or  consideration  Is  that  of  repair  and  maintenance  which  addresses  the 
Issue  of  which  faults  can  bs  put  right  In  a  faulty  systea  end  et  which  particular  times.  These 
Issues  do  have  an  Impact  on  the  reliability  of  fault  tolerant  systems  due  to  the  effect  on  the 
levels  of  redundancy  In  the  systea  at  the  start  of  a  typical  systea  run.  This  is  known  to  affect 
ths  "expoaurs"  and  "snap-shot"  times  to  be  assuaed  In  fault  trees  but  in  the  present  age  with 
auch  aore  complex  systems  operating  than  hitherto  the  possibility  arises  that  different  fault 
combinations  will  be  repaired  at  difference  times  and  traditional  analysis  methods  have  great 
difficulty  in  reflecting  these  complex  situations.  Suppose*  for  Instance*  there  are  10  different 
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potcncisl  f«ult«  vlthin  «  eyrntm  thsz.  eh«r«  are  at  laaat  1024  ayataa  configurations  sons  of  which 
nay  load  to  total  ayatan  failure.  Evan  if  tha  fault  traa  la  Itaalf  ralatlvaly  alnple  tha  nature 
of  tha  faults  and  of  tha  repair  policy  that  axlata  to  deal  with  thw  nay  not  be  and  It  can  be 
seen  that  tha  analyala  rapidly  gate  out  of  hand.  Such  a  repair  policy  la  quite  poaalbla  If  a 
dlgltal-baaad  ayatan  la  used  to  flag  up  to  tha  operator  which  faults  exist  within  tha  systen. 

This  brief  scan  llluatrataa  the  sort  of  considerations  which  beset  traditional  reliability 
nathoda.  none  of  which  apply  to  tkoa<->redundant  syatena.  After  all,  there  Is  no  need  to  detect  a 
fault  within  tha  ayaten  if  tha  syaten  cannot  function  following  the  occurrence  of  tha  fault 
anyway.  Hor  la  there  a  need  to  consider  fault-dapendanca  or  fault-propogatlon  for  single  fault 
causes  of  total  ayatan  failure,  and  tha  active  control  set  of  such  systeas  is  tha  whole  syaten, 
and  the  accoModatlon  nathoda  will  not  axlat.  fiepalr  has  to  be  innadlata,  that  Is  to  say  at  the 
end  of  each  syaten  run.  for  todays  fault-tolerant  aystens  there  la  an  abundance  of  opportunity 
for  debate  about  tha  failure  analyala  and  for  errors,  oniasiona,  and  Inaccuracies  to  creep  In. 

Thera  la  thus  a  great  need  for  and  benefit  fron  analysis  techniques  which  seek  to  autonate  and 
regulate  for  all  these  lasuea.  There  la  no  shortage  of  fault  tree  packages  which  take  the  heat 
out  of  drawing  and  calculating  ayatan  reliability  In  this  way.  But  the  one  thing  such  packages 
Insist  upon  la  that  the  user  epecifles  the  rellsblllty  nodal  and  the  failure  rates  and  the 
exposure  tines  and  the  above  considerations  show  that  It  la  there  that  errors,  onlaslons,  and 
aasunptions  can  occur.  The  Harkov  probability  technique  obviates  sons  of  those  problens  by 
looking  at  the  analyala  on  a  single-fault  as-lt-happens  baeis  and  here  too  there  le  a  growing 
nunber  of  enalyeie  pecl^gee  which  also  require  that  tha  reliability  nodal  la  In  place.  The 
capacity  of  such  packegee  to  handle  "non-etendard*^  Itana  such  as  repair  and  other  discrete 
treneltlona  le  generally  either  limited  or  too  complex  to  be  readily  usable.  Thus  there  Is  seen 
to  be  a  graet  need  to  automate  the  generation  of  the  reliability  model  Itself  Including  repair 
conaldaratione  ao  chat  tha  model  %nil  be  automatically  ptoducad  from  daalgn  aaaumptlons  that  are 
as  alnpla  and  maanlngful  aa  poaalble.  This  pepar  daecrlbes  the  mathematics  and  concepta  of 
reliability  modal  generation  tachniquea  and  their  automation  with  an  Introduction  to  how  they 
have  been  Implemented  In  a  package  developed  at  Rolls-koyce  pic. 

HARKOV  PROBABILITY  AKALYSIS  (MPA) 

The  method  proposed  by  Harkov  in  1907  is  a  mathematical  concept  which  divides  any  given  aystem 
Into  a  number  of  "ecatea**,  and  by  considering  the  '*rate  of  transition"  between  the  atatee  builds 
up  a  simulation  of  the  syatam. 

This  Is  easily  sdaptable  to  syeCea  reliability  analysis.  The  system  states  In  this  case  serve  to 
categorise  each  configuration  of  faults  within  the  syatui  and  the  reconfigurations  Chat  may  have 
taken  place  following  those  faults.  Each  state  Is  different  from  each  other  state  In  terms  of 
Che  fault  combinations  and  ayacem  reconfigurations  It  dtscrlbes  although  each  state  nay  contain 
various  such  combloaClons  within  itself.  One  of  the  states  represents  a  fully-operatlve 
zero-deficient  system  and  one  other  state  represents  all  the  various  fault  combinations  that  can 
cause  the  total  system  failure  (sonctlmes  referred  to  as  the  "death'*  state) .  The  number  of 
states  In  between  these  extremes  Is  a  function  of  the  system  complexity.  The  value  each  state 
may  take  on  at  any  given  time  t  le  the  probability  that  the  system  Is  in  that  state  at  that  time 
C  and  ao  the  sum  of  all  Che  state  values  at  any  given  time  is  always  1.  Each  non-zero  element  of 
Che  transition  matrix  represents  a  "flow**  of  probability  out  of  one  state  into  another.  The 
Harkov  mathematics  is  glvsn  In  Appendix  A. 

HARKOV  CONCEPTS  AND  PROBLEM  SOLUTIONS 

The  Markov  method  has  some  success  in  Cackling  Che  aforementioned  problema  of  reliability 
analysis.  One  obvious  advantage  that  ImedlaCely  emerges  from  using  this  method  is  that  basing 
the  equations  around  a  "flow”  out  of  one  state  and  into  another  ensures  that  the  total  system 
probability  adds  up  to  I  at  all  times.  Thus  any  Inaccuracies  In  the  fault  tree  method  due  to 
making  approxlmatlona  are  eliminated  and  a  parity-type  check  on  probability  exists  in  the  Markov 
method  that  Che  fault  tree  or  other  methods  do  not  have.  Another  obvious  advantage  that  emerges 
is  that  the  relleblllcy  analysis  reduces  to  that  of  considering  the  effect  of  single  fault 
transitions  on  the  system.  This  obviates  the  need  to  formulate  the  failure  cut-sets  directly  end 
thus  reduces  error  potential. 

The  basic  Harkov  state-flow  differential  equation  may  be  solved  analytically  (If  practical)  or  by 
an  appropriate  numerical  method.  Any  problems  caused  by  estimation  of  axposure  times  Is  thus 
sllmlnated,  as  the  state  probabilities  are  constantly  changing  as  time  proceeds.  The  need  for  a 
snap-shot  period  Is  largely  dispensed  with  as  such  a  simulation,  particularly  when  executed  by  a 
computar  process,  can  run  for  as  long  as  Is  desired.  The  snap-shot  period  effect  le  therefore 
limited  to  the  Issue  of  how  long  to  run  such  a  simulation  and  not  concerned  with  the  need  to 
choose  Che  period  and  exposure  times  to  be  compatible  with  each  other  and  to  reflect  a  "typical" 
period. 

The  Harkov  method  by  Che  Implication  mentioned  above  of  completeness  of  probability  lands  Itself 
more  naturally  (than  traditional  mathods)  towards  tbs  Inclusion  of  all  fault  combinations  and 
lotting  Che  "significance"  Issue  run  Its  course  through  the  model. 

fault  ordering  problems  are  largely  overcome  with  the  Markov  technlqua.  This  Is  achieved  by 
defining  different  states  for  esses  where  the  same  faults  have  occurred  but  In  a  different  order 
and  only  combining  Cham  Into  one  stata  If  end  when  It  la  clear  chat  the  order  didn't  matter  after 
all.  The  application  of  single  faults  to  each  given  etste  le  a  much  more  sure  way  of  determining 
tha  various  paths  to  system  fsllurc  than  that  of  trying  to  write  them  down  stralgbt-off . 
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Th«  IssuM  of  fault-dopoadonco*  fAule'^propogatloni  oporatlooal  roquiroMats.  accowodatloot  and 
dataccabllity  art  at  tha  vary  cora  of  tha  chotca  of  atataa  and  tranaltlona  In  the  Markov  nodal  of 
tha  ayataa.  Ona  approach  to  chla  la  to  raaurraee  tha  fault-traa  nantallty  and  try  8laq>ly  fron 
cartaln  ayataa  knowladga  to  dcfina  lo  aoaa  way  what  the  ayataa  atataa  ahould  ba  and  than  fit  tha 
known  ayataa  Inforaation  into  tha  varioua  atata  tranaltlona.  It  followa  that  arrora  and 
oalaalona  aada  In  tha  fault  traa  approach  can  alao  creep  in  by  doing  thla.  Thia  aathod  of 
defining  a  Markov  aodal  in  aoaa  a^irlcal  faahira  whan  uaad  In  rafarance  2  lad  to  a  caaa  where  2 
diatinct  atataa  had  bean  arronaoualy  coablnad  Into  1.  Tha  error  waa  aho«m  up  whan  applying  the 
Reliability  Modal  Generation  aathod  to  that  axaapla>  aa  that  aathod  conceptually  doaa  a 
palnataklng  **00  aaauaptlona"  approach  to  netting  up  tha  atataa. 

Repair  and  aalntananca  la  an  iaaua  alao  aora  readily  addraaaad  ualng  tha  Markov  aathod  chan  by 
aora  traditional  aathoda.  Each  atata  in  a  Markov  aodal  of  a  given  ayataa  rapreaanta  one,  or 
aayba  aora,  fault  coablnatlona.  Each  level  of  repair  provided  for  In  Che  ayataa  oparatlng 
procaduraa  can  ba  Interpreted  In  taraa  of  which  atataa  are  covered  by  Chat  level  of  repair.  So 
at  whatever  tine  parioda  within  tha  aodal  aiaulatlon  that  each  repair  level  la  auppoaed  to  ba 
carried  out,  Che  aiaulatlon  incarprata  thla  In  teraa  of  a  dlacrata  probability  change.  Tha 
atataa  which  are  kno«m  to  conalat  of  fault  coablnatlona  which  ahould  ba  repaired  at  this  level 
will  have  chair  atata  probabllltlea  aat  Co  aero,  and  other  atataa  (uaually  the  "everything 
working"  atata)  will  have  chair  probabllltlea  Increaaed  accordingly.  After  chla  proceaa  la  done 
tha  next  alnulated  run  nay  proceed.  The  aathenatlca  of  thla  are  contained  In  Appendix  A. 

In  the  literature  varioua  atCcwpca  exiat  to  uae  the  Markov  nethod  In  the  realn  of  reliability 
analyaia.  Tor  inatance  Gal,  Rarrlaon,  and  Luppold  (reference  3)  have  attempted  to  demonatrate 
tha  uae  of  the  method  for  the  reliability  analyaia  of  a  dual-redundant  engine  controller  which  la 
almllar  In  nature  to  the  example  of  aectlon  5.  The  approach  made  in  reference  3  wae  to  define 
the  atataa  in  a  raaaonable  kltwl  of  "aa  wa  go  along"  approach  with  acme  reference  to  the  hardware 
unite  within  the  ayatam.  Thla  quickly  became  complex  to  the  extent  that  It  was  naceasary  to  make 
acme  aaaumptiona  to  avoid  tha  number  of  atatca  from  getting  out  of  hand,  a  problem  that  would 
hava  been  avoided  by  the  automatic  state  generation  and  storage  capability  of  the  Reliability 
Model  Generation  (RMG)  nethod.  Also  some  fairly  specific  aeaumptlons  concerning  system  repair 
were  made  In  this  paper,  whereas  repair  policies  can  become  quite  complex.  In  another 
publication  Butler  (reference  4)  dcacrlbea  a  computer  package  for  reliability  analysis  baaed 
around  the  Markov  probability  approach  using  aoma  mathematical  reaulta  by  White  (reference  5)  and 
Laa  (rafarance  6)  giving  upper  and  lover  bounds  for  system  probabilities.  Thla  package  haa  the 
flexibility  to  Include  non-random  fault  tranaltlona  and  to  conaldar  system  reconf Iguratlona  aa 
t Ima-dependant  proceaaea,  but  requires  a  lot  of  work  to  set  up  the  etates  and  tranaltlona  and 
associated  numerical  data  and  also  doaa  not  permit  consideration  of  discrete  repair  pollciea 
being  carried  out  at  specific  tlmee. 

3.2  MATHEMATICS  OF  MARKOV  IMPLEMENTATION 

The  following  mathematical  treetment  la  detailed  In  Appendix  A.  The  basic  Markov  equation 
represent  the  fault  and  state  transition  effecta  on  state  probabllltlea  during  a  particular  "run" 
of  the  system  l.e.  1^0  it  cannot  or  will  not  be  repaired.  It  la  quite  possible  for  the  Q  matrix 
to  be  variable.  An  aeroplane  flight  la  a  typical  example  of  where  the  operational  and  atresa 
environment  of  the  eyetem  depends  on  whether  take-off,  cruise,  approach,  or  taxing  la  currently 
going  on.  A  time  aiimlatlon  can  handle  thla  failure  rate  variability  In  a  numerical  way  with  no 
problem  at  all.  In  thla  way  Che  calculation  of  £(t)  la  obCalned  given  £*(0)  the  loitial 
conditions,  end  so  £(f)  the  state  probabllltlea  at  the  end  of  a  ayatea  run  are  obtained.  During 
a  simulation  of  operation  involving  many  system  runs  the  state  probabilities  at  the  end  of  each 
run  are  obtained  from  the  probabilities  at  the  start  of  that  run.  Thla  process  can  be  carried 
out  whatever  the  duration  of  each  system  run  and  prevailing  conditions  within  it. 

The  initial  conditions  at  the  start  of  each  run  except  the  first  are  obtained  from  the  final 
conditions  at  the  end  of  the  previous  run.  This  relationship  la  determined  by  the  repair  (it 
any)  which  la  carried  out  between  each  run.  The  dlecrete  probability  transitions  that  arise  can 
alao  be  expreaaed  In  matrix-form  by  a  linear  transformation  though  In  practice  this  is 
unnecessary  vasts  of  storage  apace.  Each  different  level  of  repair  will  be  represented  by  its 
own  repair  matrix  Rl,  1  *  0  to  k.  Ro  repreaente  the  eod-of-mn  repair  and  in  many  ayatems  the 
intermediate  atatee  ere  left  alone  and  only  the  total  ayatea  failed  state  la  repaired,  In  which 
case  Ro  la  diagonal  except  for  one  off-diagonal  entry.  In  many  eyetem;}  the  top  level  of  repair 
ensures  that  all  deficient  states  ere  repaired  at  some  time  Tk.  In  thla  case  Rk  will  contain  a 
top  row  of  I's  and  O'a  elsewhere.  The  capability  to  reflect  probabilistic  repair  la  inherent  in 
these  matrices.  In  s  time  simulation  these  repair  transitions  are  carried  out  at  various  tlmee. 

Steady  application  of  all  the  above  rslatlonshlpa  enables  the  state  probabilities  £(t)  to  be 
built  up  Indefinitely  once  £*(0)  Is  defined.  It  Is  not  usual  for  Che  exact  pattern  of  future 
operational  use  of  a  ayetem  to  be  known  In  advance.  Certain  guidelines  are  often  known  and  these 
usually  formulate  Into  set  repeatable  patterna  of  system  run  duratloi  and  repair  times.  Thus  In 
theory  It  Is  possible  to  build  up  regular  relationships  between  the  state  probabilities 
iMediately  before  or  after  a  particular  level  of  repair  la  appllad.  These  relationships  can 
often  simplify  particularly  if  Rk  guarantees  complete  repair  In  which  case  £*(m.Tk)  Is  fixed  such 
that  state  1  la  set  to  1  and  the  rest  to  0. 

As  noted  already  the  end  product  that  is  required  from  a  system  reliability  analyaia  la  not  a 
stats  probability  vector  but  a  rate  per  hour,  or  similar  units,  of  total  system  failure  for  a 
given  system  design  and  a  given  operating  policy  which  Includes  run  times  and  repair  policies  and 
Intervals*  If  the  n  ststes  hsve  been  ordered  so  that  tha  "total  system  failure"  state  la  state  n 
(and  they  can  alwaya  be  so  ordered)  then  it  la  the  Information  within  the  time  sequence  pn(t) 
which  Is  used  to  actually  calculate  thla  figure.  The  potential  for  analytic  simplification  le 
atrongast  in  the  equations  governing  the  pn(t)  sequence  which  usually  haa  certa^.n  specific 
properties. 
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We  nay  raasonably  suppose  that  the  initial  value  pn*(n.f)  at  the  atart  of  any  systea  run  Is  0 
vhlch  conveys  the  neanlng  that  the  repair  policy  ensures  that  any  systen  run  will  not  connence  if 
the  system  is  already  totally  failed.  Wa  nay  also  reasonably  suppose  (by  definition  of  the  tera 
"run")  that  a  total  system  failure  may  occur  within  a  run  but  that  it  will  occur  no  more  than 
once  in  any  one  run.  We  may  further  assume  that  if  system  failure  occurs  within  a  run  that  it 
stays  in  this  state  until  the  end  of  the  run.  These  assumptions  yield  certain  usable 
Information.  It  means  that  state  n  la  a  "trapping"  state  during  a  run  so  chat  Che  probability  of 
the  system  being  in  this  state  will  never  decrease  during  the  run.  It  further  means  that  at  Che 
end  of  Che  nm  the  quantity  pc(m.f)  represents  the  probability  of  having  bad  a  system  failure 
during  that  run.  Hence  the  system  reliability  calculation  comas  down  simply  to  taking  the 
protabllltlss  of  system  raliabiliey  calculation  comes  down  simply  to  taking  the  probabilities  of 
system  failure  in  each  run  and  obtaining  a  mean  value  over  however  many  rune  seems  appropriate. 

If  the  assumptions  are  relaxed  so  that  it  la  possible  to  start  a  run  with  the  system  already  in 
Its  failed  state  than  we  would  not  be  able  to  aaaume  pn*(m.f)  ■  0.  But  wa  have  to  ensure  that  in 
this  case  the  system  reliability  calculation  does  not  multiple  account.  That  is  to  say.  a 
system  failure  that  may  have  occurred  in  a  previous  run  must  uot  be  counted  again  later.  The 
equation  for  ayatam  failure  rate  is  amended  to  take  the  Initial  probabilities  in  each  run  off  the 
final  probabilities.  It  is  often  the  case  that  terms  cancel  within  the  sunastlon  leaving  a 
sumatlon  based  on  probabilities  at  repair  intervals  rather  than  system  runs.  If  stats  n  does 
not  "trap"  then  the  calculation  does  becoste  more  complex  and  the  syatam  reliability  calculation 
is  not  so  simple.  But  even  In  this  case  it  is  to  be  hoped  that  the  information  In  the  Q  and  Rl. 

1  »  0  to  k,  natrlces  will  point  the  way  towards  the  correct  calculation. 

The  only  rcsulnlag  item  to  be  cleared  up  la  the  choice  of  the  simulation  run-time  T  (or  number  of 
systems  runs  M)  over  which  to  perform  the  probability  and  reliability  calculations.  The  hint  as 
to  what  to  do  lias  In  the  repeatability  (if  any)  of  the  syetem  run-time  patterns  and  the  repair 
Intervals  and  in  the  nature  of  each  repair  level.  If  at  some  point  In  time  complete  repair  Is 
guaranteed  and  some  ststemstit  on  the  frequency  of  such  an  event  can  be  sude  then  it  can  be  said 
that  Che  probablllatlc  deteniluatloa  of  the  system  over  one  time  period  Tk  is  repeated  for  all 
such  time  intervals  thereafter.  The  choice  of  T  is  obvious  In  this  case.  In  an  experimental 
situation  where  the  effect  of  repair  iotarvala  on  the  total  system  failure  rate  is  being 
investigated  then  whilst  in  general  the  slKulatlon  must  be  re-executed  for  each  comblnatlou  of 
repair  Intervals  it  is  worth  noting  that  some  saving  of  effort  Is  possible. 

Returning  to  the  main  point  the  outstanding  question  in  determining  the  choice  of  T  is  Che 
poesibllity  of  faults  in  the  system  that  are  either  dormant  or  are  not  repaired  at  any  repair 
level  except  after  a  further  transition  to  another  state.  If  there  is  never  a  time  at  which  full 
system  repair  is  guaranteed  (and  with  many  complex  systems  this  Is  often  the  case)  then  the 
choice  of  T  becomes  a  lot  less  clear.  Clearly  putting  T  Is  no  more  productive  for  a  Harkov 
time  simulation  than  it  Is  within  a  fault  tree  analysis.  However  it  Is  almost  certainly  true 
that  such  faults  will  be  repaired  at  some  point  in  time,  and  chose  that  are  not  night  as  veil  be 
treated  as  failed  from  the  outset,  so  the  equivalent  of  the  fault-tree  exposure  tine  is  not 
luflnlte  nor  Is  It  necessarily  related  to  system  life. 

The  question  is  simply  one  of  consideration  of  what  happens  to  a  system  with  dormant  faults  as 
time  Increases  Indefinitely.  It  would  be  natural  to  expect  the  system  failure  probability  per 
run  (after  adjustment  for  the  known  repair  Interval  considerations)  to  increase  as  time  proceeds, 
but  how  far?  Eventually  a  steady-state  solution  must  be  reached,  at  which  the  sequence  £*  (m.f.) 
will  settle  out  and  become  a  fixed  cyclic  pattern  based  around  the  known  repair  intervals.  If 
this  cyclic  pattern  were  to  be  used  to  set  the  initial  conditions  then  the  steady-state  solution 
would  be  immediately  obtainable.  The  steady-state  solution  Is  clearly  the  one  which  will  yield 
the  system  reliability  information*  just  as  where  there  were  no  dormant  faults  the  steady-state 
solution  is  obtainable  from  the  first  interval  within  which  f  11  repair  is  essured. 

The  steady  state  solution  can  be  obtained  if  the  system  run-time  and  repair  interval  patterns  are 
regular  and  If  the  matrices  lend  themselves  to  analytic  solution.  The  sequence  £*Cm.T,  )  Is  then 
founded  upon  a  constant  linear  transformational  relationship  and  the  steady  state  solution  £*  Is 
the  eigenvector  corresponding  to  the  eigenvalue  of  1.  The  nature  of  the  component  matrices  that 
make  up  this  matrix  are  such  that  the  eigenvector-eigenvalue  problem  falls  into  a  special  case 
that  avoids  most  of  the  awkward  and  complicated  msthematlcs.  The  biggest  problem  la  In  obtaining 
the  transition  matrix  for  each  syetem  run  and  combining  it  with  repair  matrices  In  several  matrix 
multiplications.  Also  because  the  matrices  in  question  are  sparse  matrices  it  is  not  In  general 
computationally  efficient  to  store  and  calculate  in  this  form. 

Consider  as  a  theoretical  example  to  illustrate  the  process  and  pitfalls  a  very  simple  system 
which  contains  two  boxes  with  failure  rates  r.  and  respectively  and  operation  Is  possible  if 
either  box  is  operating.  The  four  possible  states  are 

1  Everything  working. 

2  Box  1  failed. 

3  Box  2  failed. 

4  Both  boxes  failed  (total  system  failure). 

The  application  of  the  mathematics  to  this  system  is  added  to  Appendix  A  and  serves  to  illustrate 
that  the  Harkov  method  arrives  at  an  exact  theoretical  result  which  !.e  not  obtainable  by  fault 
tree  analysis. 
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3.3  MARKOV  PRO&ABILITT  AHALTSIS  PACKAGE 

A  package  haa  been  davalopad  at  Rolla-Royca  which  handlaa  the  Markov  Probability  Analyaia  (MPA) 
of  aoy  glvaa  ayataa  la  the  way  daacribed  above,  the  calculatlona  are  dona  nuserlcally  at  cbla 
point  In  tlBe»  no  advantage  being  yet  taken  of  any  theoretical  reaulta  that  could  ala^llfy  the 
calculatlona.  The  inforutlon  on  which  Q»  1  •  0  to  k,  arc  baaed  and  the  quantltleo  f» 

1  "  1  to  k.  arc  entered  at  the  keyboard  or  from  a  data  file  containing  the  Markov  ■odul.  The 
matrix  Information  can  alao  be  read  from  a  tranaltlon  table  data  file  as  generated  by  the  RMG 
package  and  default  valuea  are  then  Initially  aaalgned  to  the  calculation  and  output  control 
parametera.  All  varlablea  are  Interactively  changeable  and  varloua  forms  of  output  obtainable. 
After  execution  the  model  and  calculated  data  can  be  stored  In  data  files  and/or  printed  out. 

The  solution  Is  obtained  during  each  system  run  by  an  appropriate  Integration  method  applied  to 
the  basic  Markov  differential  equation.  This  method  could  be  a  linear  multi-step  method*  or  a 
Runge-Rutta  atethod*  but  the  method  so  far  implemented  Is  the  standard  Euler  method  (see  for 
exa^>le  reference  7  for  all  these  definitions).  The  rather  marginal  stability  properties  of  this 
rule  are  nullified  by  the  absolute  convergence  properties  inherent  In  the  matrix  Q.  The 
Infonaation  on  repair  la  atored  In  vector  form  rather  than  the  matrices  R. *  1  ■  0  to  k*  but  Che 
effect  Is  still  the  same.  The  simulation  package  alao  requires  the  Initial  conditions  £*(0)  to 
be  set  up.  The  simulation  is  then  executed  for  a  specific  length  of  time  and  output  of  numerical 
and/or  graphical  data  is  produced. 

The  example  from  reference  2  la  used  to  demonstrate  the  execution  of  the  MPA  package.  The  system 
is  as  shotn>  on  figure  1  and  contains  6  sensors  reading  3  different  Inputs  and  supplying  Che 
Inputs  to  3  identical  c<XBputers  in  the  manner  shown  with  Inter-conputer  coamunicstlon.  Each 
computer  performs  a  calculation  based  on  whatever  Inputs  It  has  available  either  directly  or  via 
other  computers.  Each  computer  requires  values  from  each  of  the  3  inputs  to  be  validated  by 
cross-check  between  the  2  readings  of  that  Input  or  by  model-check  from  the  other  Inputs* 
otherwise  the  computer  will  give  a  null  output  to  the  actuator.  The  actuator  averages  the 
non-null  outputs  from  the  computers.  Iliere  Are_^  types  of  failure  these  being  Che  sensor 
failures  each  with  a  fallur^  rate  rl  *  0.2  *  10  /hour*  and  the  computer  failures  each  with  a 
failure  rate  r2  *  1.0  *  10  ^/hour.  For  a  fuller  description  of  this  system  see  reference  2. 

The  Markov  model  was  read  Into  memory  from  a  transition  table  data  file  previously  generated  and 
created  by  the  RMG  package.  The  Markov  states  and  transitions  are  shown  graphically  on  figure  2 
with  the  atacea  and  the  differential  equation  Hated  on  table  1.  The  error  in  reference  2  was 
that  states  4  and  S  wars  considered  to  be  Che  same.  Appendix  B  shows  a  typical  prlnC-out 
obtained  from  executing  this  model  under  the  auspices  of  MPA.  The  displayed  data  la  split  Into  S 
sections  each  of  which  la  optional  and  these  are 

1)  Model  Information  relating  to  state  transitions  and  rates. 

2)  Opsrstlng  conditions  infomstlon  relating  to  initial  probabilities*  repair  policies  and 
Intervals*  and  time  base  variables. 

3)  Output  specification  Information  relating  to  the  combination  of  states  Into  outputs  and  the 
prlnClng/nunerlcsl/grapbical  output  control  variables  and  scales. 

4)  Tabulated  data  of  ataCe  probabilities. 

5)  System  reliability  data. 

The  output  was  so  arranged  to  display  the  probabilities  of  the  mutually  exclusive  and 
complementary  variables 

a)  Everything  working. 

b)  All  Intermediate  states  combined. 

c)  Total  system  failure. 

at  the  end  of  each  system  run  of  duration  12  hours.  The  system  reliability  information  yields 
various  Information  among  which  is  the  rate  for  total  syBtem_|allure  over  the  specified 
simulation  execution  period  which  works  out  to  be  3.955  *  10  /hour.  Figure  3  shows  the 
corresponding  plot  to  the  tabulated  data  of  Appendix  B  with  just  outputs  b  and  c  displayed  each 
on  its  own  axis  and  with  Its  own  line  identification.  Whilst  figure  3  links  up  the  end-o£-run 
probabilities*  figure  4  plots  out  the  data  for  the  same  example  at  each  calculation  point  (O.l 
hours  in  this  case).  The  stert-of-run  probability  of  total  system  failure  is  always  0  and  the 
end-of-run  probability  Increases  steadily.  The  end-of-run  system  failure  rate  eventually  reaches 
steady-state.  Figure  5  ehovs  the  same  plot  as  figure  3  on  a  100  times  greater  time  base  end  20 
times  greater  probability  axes.  When  steady  state  Is  reached  it  csi  be  seen  that  tha  average 
system  failure  rate  la  0.017  failures  per  hour  with  65T  of  all  system  runs  coaaencing  with  at 
least  one  fault  already  In  the  system, 

4  RELIABILITY  MODEL  GENERATION  (RMG) 

Whilst  the  Markov  Probability  Analysis  method  has  been  seen  to  eliminate  many  of  the  errors  and 
omissions  Inherent  In  traditional  reliability  methods  and  ell  of  the  arithmetic  approximations, 

It  Is  still  true  that  errors  and  omissions  can  occur.  Tha  trade-off  of  vlalbillty  and  co^)lexlty 
versus  assumptions  and  approximations  can  lead  to  errors  which  are  not  so  likely  with  the  Markov 
method  but  still  possible. 


Th«  funduMiital  reason  for  such  errors  and  onlssions  lies  In  the  fact  chat  a  reliability  Bodel 
needs  to  be  available  In  som  form  before  It  can  be  transferred  into  the  Markov  form  or  Into  a 
traditional  fom.  This  Means  to  say  that  the  reliability  engineer  needs  to  determine  the  system 
failure  causes  and  other  associated  infocmaCl<m  before  dravlng  a  fault  tree  or  tnrlclng  down 
Markov  states.  It  has  been  shown  already  chat  the  Markov  method  reduces  Che  problem  to 
consideration  of  single  faults  applied  to  Individual  states  rather  than  an  ad-hoc  formulation  of 
system  cuC-setSt  the  former  process  being  less  prone  to  errors.  However«  It  has  also  been  shown 
h^  It  Is  possible  to  make  assumptions  chat  are  iu>t  true  in  setting  up  the  Markov  states  even  for 
not-so-coa^lex  systems.  The  example  of  reference  2  contains  6  hardware  parts  iriilch  are  identical 
with  each  other*  3  ocher  identical  parts*  and  an  iaMsnse  amount  of  system  symetry.  This 
positively  invites  the  temptation  to  sec  up  a  simplified  set  of  system  states.  The  only  way  to 
truly  ensure  that  the  set  of  states  Is  correct  la  by  the  painstaking  approach  of  generating  all 
Che  possible  configurations  In  which  the  system  may  operate  and  Chen  to  reduce  the  number  of 
configurations  systematically  until  a  residue  of  states  Is  found.  This  sounds  worse  than  it  Is 
as  numbers  of  configurations  la  theoretically  exponentially  related  to  the  number  of  distinct 
parts  considered  but  by  caking  system  Information  into  account  yielded  for  the  reference  2 
example  only  39  working  configurations  and  these  then  reduced  to  the  residue  of  the  9  states  of 
Cable  1.  The  processes  described  here  could  be  carried  out  manually  but  any  significant  system 
complexity  would  soon  render  the  task  very  laborious  and  liable  to  error  simply  out  of  sh?er 
monotony. 

The  automation  of  the  painstaking  method  of  generating  states  and  tranaltlons  la  what  the 
Reliability  Model  Generation  (RMG)  method  is  all  about.  It  Is  about  the  transfer  of  fundamental 
system  Information*  carried  either  In  the  engineers  mind  or  on  sheets  of  paper*  into  a 
reliability  model  using  the  rules  that  are  already  Inherent  if  the  process  Is  done  manually.  At 
first  eight  It  seems  mtnd-boggllug  to  get  a  computer  to  Intexpret  system  design  but  it  will  be 
shown  that  such  a  formulation  can  be  achieved  and  that  the  system  design  Information  does  permit 
breakdown  into  certain  well-defined  categories. 

With  Che  Markov  approach  to  reliability  analysis  the  problem  of  advance  definition  of  the  failure 
cut-sets  la  already  reduced  to  that  of  definition  of  system  states.  With  reliability  model 
generation  the  problem  of  advance  definition  of  system  states  Is  further  reduced  to  that  of 
definition  only  of  Che  set  of  single  faults  and  repair  transitions  that  can  affect  the  system. 

A.l  MODEL  GENERATION  CONCEPTS 

There  are  2  stages  to  the  reliability  model  generation  mechanism  these  being 

a)  the  generation  of  all  Che  possible  operating  configurations 

b)  combination  of  configurations  by  equivalence  Into  a  residue  of  states 

The  first  process  Involves  keeping  an  Index  of  configurations  as  they  are  discovered,  a  record  of 
Che  sets  of  faults  within  each  configuration*  and  a  transition  table  each  line  of  which  lists  the 
outgoing  transitions  from  each  configuration.  In  the  reference  2  example  there  are  9  distinct 
hardware  parte  and  model  generation  is  based  around  9  fault  events.  Table  2  shove  the  manual 
application  of  Che  model  generation  concept  to  this  example  and  the  resulting  transition  table. 

It  can  be  seen  Chat  the  process  is  built  up  from  configuration  1  (Che  "everything  working" 
configuration)  by  systematic  application  of  each  fault  event  Co  each  configuration  until  all 
configurations  have  been  analysed  In  this  way.  The  system  information  Is  used  to  determine 
whether  system  operation  Is  still  possible  there  being  no  need  to  consider  configurations  In 
which  total  system  failure  has  occurred.  Repair  transitions  may  or  may  not  be  analysed  In 
parallel  with  the  fault  transitions. 

If  there  are  v  fault  events  that  can  occur  within  the  system  then  these  events  will  form  the  bulk 
of  the  set  of  events  to  be  applied  to  each  configuration.  If  It  desired  to  analyse  repair 
transitions  also  Chen  assuming  end-of-run  repair  Is  definable  and  also  k  further  repair  levels 
are  assumed  then  k-^-I  repair  transitions  are  also  applied  to  each  system  configuration.  So  the 
length  of  each  line  of  the  transition  table  la  either  v  or  v+k+l  depending  on  whether  repair  is 
being  incorporated  or  not. 

The  traneltlons  caused  by  the  v  fault  events  correspond  to  the  entries  in  the  Q  matrix.  The 
tranbitlons  caused  by  the  k-^1  repair  events  correspond  respectively  to  the  entries  in  each  of  the 
repair  matrices  Rl»  1  *  0  to  k  or  to  any  representation  In  vector  form.  The  application  of  esch 
fault  Co  each  configuration  is  the  process  ii^ich  a  reliability  engineer  could  do  manually  using 
knowledge  of  Che  system.  The  application  of  the  repair  policies  Is  simply  that  of  interpretation 
of  each  repair  level  in  ^urn  Co  the  set  of  faults  v^lthin  the  configuration  under  consideration  to 
determine  If  Chat  configuration  is  repairable  at  Chat  repair  level.  To  perform  this  process 
automatically  requires  certain  Information  to  be  entered  into  Che  RNC  package  in  advance  of  model 
generation  which  will  then  be  processed  in  a  way  which  will  achieve  the  correct  transitions.  The 
information  required  Is  described  in  section  4.2.  The  primary  task  remaining  is  to  define  the 
set  of  single  fault  events  Chat  can  occur. 

It  is  possible  for  a  complex  system  to  have  within  it  a  multitude  of  components.  Fowever,  It  is 
also  likely  Chat  many  of  these  components  will  have  exactly  the  same  effect  on  system  operation. 
It  la  therefore  entirely  reasonable  to  treat  such  components  within  a  zeliablllty  analysis  as  if 
there  were  Instead  one  component  with  a  failure  rate  made  up  of  the  total  of  the  rates  of  failure 
of  the  individual  components.  This  collection  of  components  classified  by  system  effect  is  known 
as  a  "block"  within  the  reliability  model. 

Very  often  a  system  Is  designed  on  a  modular  basis  and  this  translates*  in  reliability  terms* 

Into  the  fact  that  all  the  components  In  one  module  could  have  the  same  failure  effect  on  the 


•'♦ft 


T 


34-8 


1 


syscw.  Thue  a  hardwara  nodula  and  a  rallablllty  nodal  block  could  represent  one  and  the  sane 
thing.  Even  where  a  hardware  nodule  contains  conponents  with  different  system  affects,  it  Is 
often  possible  to  consider  a  "worat-caae**  scenario  in  order  to  combine  the  components  into  a 
single  reliability  model  block.  This  would  have  the  effect  of  Introducing  a  conservative 
assumption  and  any  model  generated  with  such  an  assumption  would  give  a  higher  figure  for  total 
system  failure  than  the  true  answer.  These  assumptions  are  best  avoided  if  possible.  To 
represent  reality  It  Is  necessary  to  separate  conponents  strictly  by  system  effect.  But  a 
complex  system  many  necessitate  some  coid>inatlon8  as  above.  It  Is  Important  to  stress  here  that 
these  assumptions  are  conservative  ones,  and  as  such  lead  to  an  upper  bound  for  the  total  system 
failure  rate,  and  that  this  la  the  correct  way  round,  rather  than  to  consider  system  failure  sets 
and  risk  omissions. 

The  entire  system  Is  classified  Into  these  various  "blocks"  according  to  system  effect.  So  whet 
la  meant  by  system  affect  In  this  case?  It  is  concerned  trlth  such  things  as  fault-propogatlon, 
operational  logic,  repair  logic,  and  fault  types,  and  various  other  concepts  which  become  clearer 
when  the  specific  Information  In  considered.  Fault-propogatlon  basically  Is  concerned  with  the 
effect  of  faults  In  ona  block  upon  ocher  blocks.  Operational  logic  la  concerned  with  what 
hardware  needs  to  be  operating  in  order  to  maintain  system  operation.  It  must  be  stressed  again 
that  system  design  is  usually  related  to  this  requirement  rather  than  to  the  failure  cases,  and 
in  any  case  omissions  from  the  operational  logic  are  conservative.  Repair  logic  states  the 
repair  policy  In  terms  of  the  model  blocks  and  Is  therefore  classified  as  a  system  effect.  Fault 
types  considerations  Is  a  recognition  that  within  a  block,  within  a  component  even,  failures  can 
exist  which  exhibit  different  failure  modes  and  such  failure  modes  are  therefore,  if  not  already 
separated  by  system  effects,  classified  by  detection  methods.  The  total  of  all  the  fault  types 
within  all  blocks  forms  the  set  of  v  fault  events  required  for  the  model  generation  process. 

So  given  these  concepts  which  should  theoretically  define  the  reliability  model  blocks,  th%  real 
question  is  how  the  blocks  are  defined  in  practice.  Inevitably  attempts  will  be  made  to  tie  the 
blocks  In  with  the  hardware  modules,  and  it  is  already  recognlaed  that  this  can  and  should  be 
dona  on  a  conservative  basis,  so  that  any  fault  within  a  block  will  cause  the  entire  block  to  be 
deemed  as  having  failed.  The  system  design  assumptions  are  the  starting  point  for  block 
definition,  particularly  if  this  Is  modular.  The  system  design  will  provide  Information  in  the 
required  categories.  After  this  the  Failure  Modes  and  Effects  Analysis  (FMEA)  for  the  system  or 
for  the  modules  of  the  system  Is  brought  into  play.  Within  the  FHEA  every  poaslble  s^.ngle  fault 
is  (or  should  be)  listed  there,  and  certain  information  is  provided  that  Is  used  to  classify  the 
faults  within  the  reliability  model.  The  FM£A(b)  will  usually  have  the  effect  of  taking  the 
block  definition  away  from  Its  modular  starting  point. 

The  Important  thing  to  note  here  la  that  the  combination  of  syatem  design  assumptions  and  the 
system  FM£A(6)  are  used  to  make  the  relleblllty  model  steadily  less  conservative  and  more  real. 
The  ultimate  starting  point  Is  to  assume  that  the  entire  system  can  be  classified  Into  Just  one 
block.  This  represents  a  return  to  the  non-redundant  systems  mentioned  right  back  Ic  section  i. 
Cfae  of  the  system  design  assumptions  and  FH£A(b)  then  help  to  break  the  system  down  Into  more  and 
different  blocks  to  get  as  near  to  reality  as  desired.  Providing  that  each  breakdown  is  not 
contradictory  to  the  system  design  assumptions  or  FHEACs)  then  the  resulting  reliability  model  Is 
guaranteed  to  provide  an  upper  bound  for  the  system  failure  rate. 

Once  the  blocks  are  fully  defined,  and  the  fault  types  within  each  block  are  fully  defined,  then 
the  total  number  of  fault  types  summed  over  all  the  blocks  represents  the  number  of  different, 
mutually  exclusive  and  mutually  complimentary,  single  faults  tliat  can  occur.  These  are  the  fault 
events  that  are  applied  to  each  generated  configuration.  In  the  reference  2  example  there  were 
considered  to  be  9  blocks  exactly  corresponding  to  the  9  hardware  parts  as  all  faults  In  any  one 
part  yielded  one  specific  system  effect.  Similarly  all  9  blocks  bad  Just  I  fault  type  each  as 
there  is  no  distinction  wlthlu  any  hardware  part  In  respect  to  methods  of  detection  of  the  faults 
within  that  part. 

Having  defined  the  blocks  and  fault  types  and  set  up  the  system  Information  based  around  these 
blocks  then  configuration  generation  takes  place  either  manually  or  automatically  using  the  RNG 
package.  The  second  part  of  the  process  Involves  reducing  the  configurations  Into  a  residue  of 
states.  This  is  done  by  comparing  lines  on  the  transition  table  and  determining  If  any  2  lines 
are  equivalent  to  each  other.  It  must  be  stressed  that  even  where  2  configurations  are  similar 
In  terms  of  containing  equivalent  hardware  that  those  configurations  are  not  necessarily 
equivalent  In  terms  of  ot^tgolog  transitions.  The  hardware  equivalence  within  the  system  Is  used 
to  help  determine  transition  table  equivalence  but  Is  not  to  be  confused  with  It.  Table  3  shows 
the  final  transition  table  for  the  residue  of  states  after  equlvalencing  table  2.  Note  that 
states  4,  5,  6  sll  contain  equivalent  hardware  but  their  transition  table  lines  are  not 
equivalent.  These  statej  correspond  to  the  definitions  on  table  I  and  every  one  of  the  39 
configurations  on  table  2  flte  Into  one  of  the  states. 

DESIGN  INFORMATION  DATA 

The  design  information  Is  that  which  Is  required  In  advance  of  carrying  out  the  model  generation 
process.  This  Information  Is  that  which  s  rellsblllty  snglneer  uses  on  a..  Implicit  basis  to 
effect  either  failure  cut-sete  or  Markov  model  states  or,  in  this  new  formulation,  the  generation 
of  configurations  from  a  glvsn  block  structurs.  In  ordsr  to  automate  the  process  sach  place  of 
design  Information  needs  to  be  formulstsd  and  will  be  Illustrated  using  the  same  example  so  far 
considered. 

So  far  there  are  9  distinct  types  of  dsslgn  Information  that  have  been  automated  although  it  Is 
not  clalmsd  that  this  formulation  is  unique  or  necessarily  complete.  The  9  types  are 
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1)  Block  Stxucturo. 

2)  Fault  Propotacloa. 

3)  Oparatloaal  Logie. 

4)  Repair  Logie. 

5)  Fault  Typaa. 

6)  Sataction  Kathoda. 

7)  Equivalauca  of  Hardvara. 

8)  DoTBant  Logic . 

9)  Fault  Count. 

Tha  flrat  Infonation  that  la  raqulrad  by  tha  WG  paekaga  la  tba  block  atructura.  Thia  can  ba 
dona  quite  flexibly »  ao  aa  to  taka  Into  account  the  poaaibillty  of  a  nodular  dlvialon  anong  tba 
parta  of  tba  ayatan.  For  tha  glean  axanpla  a  block  atructura  of  9  top-level  blocka  la  tha 
obeioua  atartlng  point  although  in  practice  auch  a  ayatan  nay  yield  further  braakdoim  of  tha 
conputera  or  include  faulta  in  tha  highvaya  or  whataear.  If  it  uaa  eonaldarad  that  tha  9  blocka 
rapraaant  a  conaareatlea  aituation  and  the  conputera*  for  axanpla*  are  found  to  have  a  non-^alnpla 
reliability  analyala  of  thalr  own  than  thia  can  ba  atructurad  by  ratalnlng  tha  9  top-laeal  blocka 
and  creating  aub^lavala  to  handle  any  further  aub-diviaion  of  faulta.  Thaaa  aub-lavala 
conatltuta  reliability  aub-nodala  tha  Cop  aeant  of  which  faada  Into  tha  next  higher  aub~nodal. 

Tha  real  benefit  of  nultl-'laeal  block  atrueturaa  conaa  out  In  caaaa  where  Che  reliability  nodal 
for  the  whole  ayatan  la  built  up  fron  tha  reliability  nodal  of  Ita  conponant  nodulee.  There  la 
nuch  flexibility  to  the  nathod  and  for  now  it  will  ba  aMunad  within  tha  axanpla  ayatan  Chat  Juat 
one  laeal  of  nodal  axlata  with  9  blocka.  Tha  blocka  are  naned  on  table  4. 

Tha  aacond  InfomaClon  Chat  ia  raquirad  by  tha  IMG  package  ia  tha  fault  propogatlon  infornatlon. 
Thia  Infomation  la  apaclflad  aapaxataly  for  each  and  aeary  aub-nodal  within  tba  block  etructure. 
It  eonaiata  qulta  aliqily  of  a  Hat  of  propogatlon  affects  which  are  put  down  until  all 
propogatlon  affects  that  can  happen  within  tha  aub>nodal  are  conplataly  apaclflad.  Each 
apaclflad  propogatlon  affect  takes  tha  fom  of 

a)  A  logic  string  specifying  a  fault  conblnation  which  cauaaa  the  propogatlon  effect. 

b)  lodiestica  of  wbathar  fault  la  real  or  Inaginary. 

c)  A  list  of  blocks  which  are  affected  by  tha  propogation. 

Tba  logic  string  can  ba  nade  of  ’AMD*  and  'OR*  gates  between  Indicaa  of  blocka  within  the 
aub-nodel.  Tha  indication  of  whether  fault  la  real  or  inaginary  la  Intended  Co  handle  2 
different  types  of  fault  propogatlon.  Sonatinas*  a.g.  alactrical  power  faults*  the  failure  of 
other  harilwara  parta  la  real.  In  other  cases*  a.g.  where  an  input  sensor  reading  is  fad  to  2 
different  places*  the  fault  propogatlon  affect  reflects  an  aqulTalant  ayatan  affect.  In  thaaa 
caaaa  the  axlatenca  of  tha  propogatlon  affect  enables  the  operational  logic  to  be  slnpliflad  and 
also  raducaa  tha  nunber  of  working  configuratlona  generated.  The  lists  of  blocka  affected  apaaka 
for  itself.  Tha  rafaranea  2  axanpla  has  3  propogatlon  affects  within  Its  one  aub-nodel.  These 
affects  specify  that  if  one  of  tha  3  conputera  fella  than  tha  2  aenaora  which  are  tad  into  the 
ayatan  through  that  conputer  (figure  1)  are  no  longer  accaaalbla  to  the  ayaten.  Table  5  ahowa 
tha  full  Hat. 

Tha  third  infomation  that  ia  required  by  the  RMG  pack^a  ia  tha  operational  logic.  This  la  also 
entered  separately  for  each  aub-nodal  and  apacifiaa  for  that  aub-n^al  tha  conblnatlona  of  blocka 
which  need  to  ba  operating  In  order  for  the  aub-ayatan  described  within  the  eub-nodel  to  continue 
to  operate.  Thia  is  tha  right  approach  aa  tha  nora  co^inatlons  that  are  added  to  the  operational 
logic  tba  nearer  tha  nodal  will  gat  to  rapraaanting  reality  but  at  tba  aana  cine  ensuring  that 
reality  ia  approached  fron  the  consarvaclwa  aide  by  only  adding  any  particular  conblnation  to  the 
operational  logic  string  whan  it  ia  establiahad  that  operation  la  poaalbla  with  this  conblnation. 
The  operational  logic  that  nay  ba  entered  can  handle  '(Ml*  and  'AMD*  logic.  It  can  further  cowar 
a  type  of  'NOT*  logic  that  allows  different  operational  logic  conblnatlona  tc  ba  considered  in 
tha  awant  of  apaclflad  faulta  hawing  already  occurred.  This  is  particularly  relevant  to 
aoftwara-baaad  ayatana  which  ia  the  event  of  faulta  within  tha  Inconing  data  can  quickly 
reconfigure  to  do  antiraly  different  calculations  using  an  entirely  different  sat  of  inconing 
data.  It  la  also  applicable  to  altamatiwe  power  supply  type  altuatloDs  vha*'e  electrical 
hardware  parta  nay  be  dapowarad  and  than  powarad-up  again.  In  tha  currant  Maapla  it  will  be 
aaamad  that  no  such  altamatiwa  control  nodes  are  awallabla.  Tba  ^aratlonal  logic  for  thia 
ayatan  la  baaed  around  tha  raqniranaat  to  have  certain  aanaor  raadinga  awallabla  to  tba  ayatan. 

It  baconaa  apparent  when  studying  tha  design  assumptions  that  the  ayatan  will  operate  if  there  la 
at  least  one  sensor  of  each  input  type  A*  B*  C  or  if  there  are  2  pairs  of  similar  aenaora 
awallabla.  It  ia  apparent  that  if  enough  aenaora  are  awallabla  to  tba  conputera  than  It  is 
certain  that  there  are  enough  conputera  to  process  than  and  tba  fault  propogatlon  logic  haa 
ensured  that  the  ayatan  reflects  this  face.  Tba  logic  string  for  which  it  la  known  that  ayatan 
operation  can  taka  place  la  given  on  table  5. 

Tha  fourth  infomation  that  la  requited  by  tha  RMG  package  la  the  repair  logic.  This  infomation 
la  eoncamad  with  stating  tha  assunad  operational  repair  policies  in  tarns  of  tha  defined  block 
structure.  This  la  not  dona  on  a  aub-nodal  basis  as  repair  policies  era  in  general  fomulatad. 
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or  Mr«ly  just  hsppcB.  on  s  systs^-vlds  bssls  using  tbs  low-Isvsl  blocks.  Ths  los-'Xsvsl  blocks 
srs  tboss  for  which  no  further  sub-aodsl  exists  so  thet  in  the  exeaple  systen  there  sre  9 
low-level  blocks.  This  logic  ls»  in  essence*  of  contrsry  nsturs  to  Che  rsnsiader  of  Che  design 
Infonstlon  ss  it  elone  is  concerned  not  with  «diet  cen  go  wrong  within  Che  systra  during  e  system 
cun  but  with  whet  esn  be  put  right  between  eech  run.  It  is  often  deslrsble  to  co^^re  several 
repair  policies  In  order  to  determine  effect  on  the  system  relleblllty  figures.  There  ere  2  ways 
of  asking  such  e  comparison 

a)  Generate  the  model  without  reference  to  repair  transitions  and  chan  determine  manually  the 
application  of  each  repair  policy  to  the  generated  model  states  and  enter  Into  the  MPA 
package . 

b)  Generate  sepstste  reliability  models  for  each  different  repair  policy  thus  making  eech  model 
a  unique  combination  of  system  design  end  associated  repair  policy. 

The  nuid»er«  k*  of  scheduled  repair  levels  is  required  followed  by  a  logic  string  for  each  of  the 
1:4*1  potential  repair  ttansitlocs  corresponding  to  the  Informetlon  within  the  matrices  hi,  1*0 
to  k.  Again  *AVD'  and  *0t'  logic  la  used  for  the  logic  at  each  repair  level  and  again  approach 
from  the  eonsarvatlva  aide  la  assursd  ss  each  logic  string  Is  built  up.  For  ths  currant  sssmpls 
no  rspalr  sssnmptlons  srs  made  sxcept  that  of  specifying  thet  total  system  failure  is  rspalred  at 
the  end  of  the  run  in  which  It  occurs  which  Is  already  Inhsrsntly  sssmed  in  the  FMG  package. 

Thus  for  this  modal  repair  considsrstlons  can  bs  omittsd  altogsther  ss  on  tsbls  2.  If  ths  rspalr 
assumptions  wars  epeclfled  It  would  be  done  by  putting  k  •  0  end  specifying  the  logic  string  for 
rspalr  level  0  ea  blank.  Thle  would  simply  add  one  column  to  table  2  and  every  entry  would  be  a 
and  ao  the  equivalence  of  lines  on  the  table  would  be  unaffected. 

The  fifth  iaformatlon  that  la  required  by  the  RMC  peckege  la  that  of  fault  typea  within  each 
block.  Thla  Information  apeclfiaa  for  each  low-laval  block  within  the  system  whet  further 
eub-dlvlelone  exist  due  to  existence  of  different  methods  of  detection.  Any  feult  within  e  block 
will  ceuse  thet  block  to  be  deemed  ce  felled  but  whether  the  failure  Is  known  or  unknown*  and 
hence  sccomsodated  according  to  ths  operstlonsl  logic  sltsmetlvesi  depends  on  the  method  of 
detection  stkd  whether  that  datactlon  ia  working  succaaafully.  Tbua  each  fault  type  within  each 
block  la  e  eeperete  feult  event  as  the  system  affect  la  potentially  different  In  each  case.  The 
Information  entry  that  ia  esquired  Is  eia^ply  to  stats  the  number  of  fault  types  In  ssch  low-levsl 
block  In  turn.  Ths  total  fsllurs  rats  for  each  block  Is  divided  among  Its  fault  types  end  the 
contributing  component  faults  ere  cleeelfled  im  these  fault  types.  The  total  nunbet  of  fault 
types  over  all  ths  low-levsl  blocks  within  the  system  defines  the  total  number  v  of  fault  events 
to  be  applied  as  potential  transition  evanta  from  any  ona  atata  Into  othar  atataa.  In  tha 
currant  axampla  with  just  one  sub-model  end  9  low-level  blocks  It  Is  dsclsrsd  that  aach  block  haa 
Just  ona  fault  type  giving  a  total  of  9  fault  avante  aa  shown  on  table  2. 

The  sixth  Information  raqulrad  by  the  KMG  packaga  la  the  detection  metboda  for  each  fault  type 
within  aach  block.  Each  datactlon  method  is  expressed  ss  s  logic  string  which  ststss  which  block 
or  combination  of  blocks  nesds  to  be  opsrstitig  et  the  time  the  feult  Is  applied  to  each 
configuration  In  order  for  Che  fault  to  bs  successfully  detsetsd.  If  tbs  required  block 
comblnetlon  Is  not  svsllebls  at  the  elms  when  it  Is  sssded  then  tbs  fault  will  be  registered  ee 
undetected.  Ageln  'AMD*  end  'Ok*  logic  to  set  up  tbe  detection  method  comblnetlona  for  eech 
feult  event.  Ths  currant  sxsmpls  has  9  fault  events.  The  detection  method  philosophy  states 
that  each  sensor  fsllurs  can  bs  detected  by  its  own  computer  and  sscb  computer  fsllurs  Is 
detected  by  itself.  Tbe  eenaor  failure  detection  Is  thus  always  certain  ss  ths  fault  propogstion 
logic  Insists  that  If  s  computer  Is  felled  then  so  sre  both  Its  sensors  sod  tbs  Issue  of  future 
sensor  fsllurs  would  never  arise.  The  coi^uter  detection  method  ia  another  way  of  saying  rbst 
tha  aysCem  will  always  detect  computer  faults*  due  In  this  ease  to  tbe  actuator  ignoring  any  null 
output.  The  logic  strings  for  the  detection  methods  srs  ss  on  table  4. 

Tbs  seventh  Information  required  by  the  RMG  package  la  the  statements  on  squlvalsncs  of  hardware. 
This  ia  entered  for  every  fault  event  within  tbs  system  and  spsclflss  that  ssch  fault  type  may 
contain  idsntlesl  hardware  parts  to  another  fault  type  elsewhere  In  ths  system  end  thus  have  ths 
asms  fsllurs  rate.  It  has  bass  noted  slres4fy  that  this  type  of  Informstion  about  ths  syssmtry  of 
s  system  In  hardware  terms  Is  often  mlstsksnly  used  to  assume  that  2  or  more  system 
configurations  with  slml'jr  hardware  faults  are  squlvslsnt  configurations  sad  can  bs  combined 
into  tbe  same  stats  of  ths  rslisblllty  modal.  Ths  true  definition  of  equlvelence  of 
configurations  lies  in  ths  various  transitions  from  the  conflguretlons.  It  Is  la  determining 
squlvalsncs  of  lines  of  the  transition  tsbls  that  tbs  hardware  equlvelence  la  tsksa  into  account 
but  not  la  ths  gcasrstlon  of  configurations.  Ths  bsrdvsrs  equlvslsncs  in  the  currant  exsmpls 
concerns  the  fact  that  each  sensor  Is  hardware  equivalent  to  each  other  sensor  sad  similarly  for 
ths  computers.  The  logic  entry  is  that  each  sensor  is  mads  equivalent  to  sensor  XA  and  each 
computer  made  squlvsleat  to  computer  X  ss  shows  on  table  4. 

Tbs  eighth  Information  required  by  the  IMG  psehsge  is  tbe  dormant  logic  which  la  eoncsrnsd  with 
whether  faults  which  srs  undetected  durli^  a  aystem  run  may  beco  m  detected  between  system  runs. 
If  soma  unknown  faults  do  bscoms  detectod  In  this  way  than  they  can  be  censidersd  upon 
application  of  the  rspalr  logic.  If  repuir  la  not  applied  then  ths  next  aystsm  nm  starts  off  in 
a  different  configuration  which  may  or  may  not  bs  la  aame  atata.  Thus  such  considsrstlons  lead 
to  potential  dtacrets  state  trsaalcloaa  wikich  would  also  bs  rsfiseted  in  ths  mstricss  Rl*  1*0 
to  k*  along  with  ths  repair  logic.  The  Iaformatlon  is  dons  on  a  low-level  block  basis  and  la 
entarod  simply  sa  a  'Tea*  or  'Mo*  to  the  quoatlom  of  whotbar  the  failure  of  each  block  In  turn 
could  bo  ao  detected.  In  the  current  oxaivle  there  ia  no  possibility  of  undatoctsd  faults  tn  any 
block  and  the  snswora  to  ths  questions  srs  irrolsvant  and  table  4  shews  that  'Mo*  is  snswsrsd  for 
ssch  block. 
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Tb«  aisth  InforaatloB  required  by  tb»  BIG  packas*  ia  tba  fault  count  logic.  Thla  eoncapt  la  not 
spaelflcally  ralatad  to  ayataa  daalgn  aaaunptlona  and  la  optional.  It  la  Intandad  to  aaalat 
conputatlon  by  trying  to  find  tha  optlnon  balaaca  batwaan  ouabara  of  conflguratlona  ganaratad  and 
tba  anount  of  conaarvatlan  built  in  by  raduelng  ouch  nuabata  of  conflguratlona.  Tha  eoaeapC 
arlaaa  out  of  a  poaalblllty  that  tha  WG  paefcaga  could  ganamta  a  grant  aultltuda  of 
conflguratlona  In  lAlcb  tha  ayatna  could  contlnoa  to  oparata*  nany  of  which  would  corraapood  to 
■ultlpla-fault  caaaa  and  ba  wary  wuch  laaa  llkaly  to  occur  than  conflguratlona  with  fawar  faulta. 
It  la  oftan  juatlflabla  to  conaanratlwaly  aat  a  cut>«ff  point  by  coilacting  tba  high  fault-nunbar 
conflguratlona  togathar  within  tha  atata  corraapoadlng  to  total  ayatan  failure.  So  during  tha 
nodal  ganaratlon  procaaa  a  fault  count  limit  nay  ba  aat  at  which  ayatan  fallnra  la  aaauaad.  Tba 
Infomatlon  that  la  raqulrad  during  tha  daalgn  infomatlon  data  entry  la  to  aat  a  count  to  each 
low-lawal  block  within  tha  ayatan.  If  thla  block  than  falla  during  a  ayatan  run  tha  appropriate 
fault  count  la  added  to  tha  'acora*  until  the  pacified  lialt  la  raachad.  Thla  count  can  ba 
different  for  different  blocka  and  can  ba  0  aa  wall  aa  any  poaltlwa  nunbar.  In  the  currant 
azanpla  It  la  propoaad  not  to  conaldar  limiting  faulta  In  thla  way  and  ao  tha  count  for  each 
block  la  aat  to  0  aa  ahoim  on  table  4. 

4.3  RELIABIUTT  MDDIL  GBRkATIOg  PACKAGE 

A  package  haa  bean  davalopad  at  tolla-Koyca  pic  idiich  handlaa  tha  Kallablllty  Modal  Ganaratlon 
(IMG)  of  any  glwan  ayatam  atartlng  fron  tha  entry  of  tha  daalgn  infocnatlon  aa  daacrlbad  above. 
Tha  Infomatlon  la  antarad  at  tha  keyboard  or  from  a  daalgn  infomatlon  data  file.  Thla 
Infomatlon  la  chan  coded  up  Into  a  fom  which  will  enable  rapid  computation  during  tha  modal 
generation  procaaa.  When  the  deaign  Information  la  fully  aaterad  thm  It  may  ba  intaractlvaly 
alcared  and  vrlttan,  if  appropriate*  to  e  deaign  information  data  file.  Whan  tha  Information  la 
deemed  correct  than  the  modal  ganaratlon  can  taka  place.  Thla  la  dona  flratly  by  generating  tha 
varloua  ayatan  conflguratlona  chat  atlll  allow  ayatm  operation. 

Tha  Index  of  operating  conflguratlona  la  inltlallaad  wlUi  configuration  I  which  la  tba 
fully-oparatlva  no^faulc  configuration.  Thla  configuration  la  than  analyaad  by  application  to  It 
of  each  of  tho  v  fault  avanta  aaparataly  (and  each  of  tba  kfl  repair  avanta  If  aalactad)  and 
aevaral  nore  operating  conflguratlona  are  diacovarad  and  added  to  tba  Index  of  ouch 
conflguratlona.  Tha  first  line  of  the  cranaltlon  table  la  made  up  of  the  indlcaa  of  the 
conflguratlona  raaultlng  from  tranalciona  that  taka  place  on  occurranca  of  the  varloua  fault  and 
repair  avanta.  Prom  chan  on  each  configuration  in  tha  Indaa  llat  la  analyaad  for  outgoing 
ctaualclona  In  exactly  tha  aama  way*  tha  Ileaa  of  tha  tranalclon  table  are  built  up*  further 
conflguratlona  added  to  the  llat  whan  diacovarad*  until  all  configuraclone  are  analyaad  In  thla 
way. 

At  the  application  of  each  fault  avant  to  each  configuration  eartain  oparatlona  art  carried  out. 
Flratly  if  the  block  corraapondlng  to  tha  fault  event  la  already  la  a  failed  condition  within  tha 
configuration  then  thla  avant  cannot  ba  applied  again  and  the  tranalclon  table  ascry  la  blank  to 
indicate  no  change  In  tha  configuration.  Aaaumlng  tba  fault  event  la  a  new  one  to  tba 
configuration  under  conaldaratlon  chan  tha  datactablllty  of  tha  fault  la  evaluated  from  tha 
detection  method  and  the  axlatlng  faulta  within  the  configuration  ao  thnt  tba  block  la  flagged  op 
aa  failed  either  undataecad  or  datactad.  Tha  fault>propogatlon  affaeta  are  than  employed  to  pane 
tha  fault  onto  other  blocka  within  the  eub*-modal  If  appropriate  and  following  tble  tba 
operational  logic  la  evaluated  to  daCamlua  If  tha  aub-ayatam  defined  by  tba  aub  modal  la  atlll 
operating  or  haa  failed.  If  it  haa  failed  than  the  fault  la  paaaad  onto  to  tha  next  higher  level 
aub-modal  and  tha  procaaa  repeated  until  total  ayatam  operability  la  datamlnad.  If  tha  ayatam 
haa  failed  ao  that  operation  la  not  poaalblo  than  tba  tranaitlon  table  entry  la  aat  op  to  flag 
thla  fact.  If  the  ayatam  la  atlll  operating  cben  tba  new  conflguratlpn  will  need  to  ba  added  to 
tha  index  of  oparatlog  conflguratlona  unlaaa  the  configuration  la  already  In  thla  llat  and  tha 
list  la  checked  to  aaa  if  thla  la  ao.  Either  way  the  diacovarad  configuration  will  have  or  ba 
given  a  place  in  tba  llat  and  the  transition  table  entry  rafarancaa  It. 

At  the  application  of  each  repair  avant  certain  ^arationa  are  carrlad  out.  Flratly  tba  dormant 
policy  la  applied  to  tba  undatactad  faulta  to  aaa  If  they  are  to  be  transferred  to  tba  atatua  of 
datactad  faulta.  Following  thla  the  repair  policy  corraapondlng  to  tho  repair  level  under 
conaldaratlon  la  applied  to  tho  doCactad  faulta  to  datamlno  If  repair  takaa  place  at  thla  level. 
If  repair  la  to  bo  carried  out  on  this  configuration  at  this  level  than  tba  transition  table 
entry  ahowa  a  transition  to  tba  "avarytblng  working”  configuration.  If  repair  la  not  to  ba 
carrlad  out  and  no  undatactad  faulta  have  become  datactad  faulta  than  tha  tranaitlon  table  entry 
la  blank  to  show  tm  change  la  coBfiguxatlon.  If  thaxa  are  aoma  undatO’^tad  faulta  baeomlng 
datactad  than  tha  configuration  llat  la  checked  exactly  aa  for  tha  faxUt  avanta. 

When  tba  conflguratlona  llat  and  transition  table  la  complata  than  tha  procaaa  of  IdmtlfylBg 
aquivalanca  starts*  but  thla  procaaa  can  also  taka  place  at  Intamadlata  tlmaa  If  it  la  daaltabla 
to  cut  down  on  mamory  atoraga  and  llat  checking  tlmaa  during  tha  configuration  ganaratlon 
procaaa.  Tha  procaaa  of  aqulvalanco  lovolvaa  cohering  llnaa  on  tha  transition  table  taking 
hardware  aquivalanca  Into  account.  If  2  Ilaaa  are  Identical  than  tha  conflguratlona  are  daamad 
equivalent  and  tha  configurations  llat  la  reduced  by  one  for  each  such  aquivalanca  obtained. 

This  prcccaa  la  Iterative  as  the  aquivalanca  of  aoma  conflguratlona  will  usually  lead  on  to  tha 
aquivalanca  of  others.  Whan  all  tha  aquivalanca  ralatlonablpa  are  carrlad  out  than  tha  final 
raaldua  of  configurations  and  tha  corraapooding  tramaitlon  table  represent  tha  mlnlmiim  ao^ar  of 
atataa  of  tha  reliability  modal.  These  will  ba  tha  states  that  art  used  In  the  Markov 
probability  analyala.  Thus  In  tba  final  fom  of  tha  rafaraaca  2  example  tha  tranaitlon  table  la 
9  by  8  for  tha  9  fault  avanta  (there  are  ao  repair  coaaldaratlona)  and  tba  8  operating  atataa. 

The  final  residua  of  atataa  and  tranaltlona  la  this  fom  can  than  ba  put  onto  a  trmaltlon  table 
data  file  ready  for  use  by  tha  MPA  package. 
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To  ftirtbor  lllttstrot*  eh*  pros***  l*t  a*  mmad  eh*  r*f*r*Bc«  2  oxsapl*  aod*!  slightly  in  2  wsys. 
Firstly  1st  us  spply  s  rspslx  polley  thst  spsclflss  2  Isvsls  of  sehsdnlsd  r^slr.  At  Isvsl  1 
rspslr  tskss  pises  If  sny  coapotsr  Is  fsils4«  snd  st  Isvsl  2  rspslr  tskss  pises  If  sny  ssnsor  hss 
fslls4.  Ths  dsslgn  Informstlon  dsts  sstry  Is  sltsrsd  only  se  ths  rspslr  logic  stsg*.  Bsr*  k  •  2 
Is  ststsd  snd  3  logic  strings  srs  sncsrsd«  Ths  first  string  rsaslns  blsnk*  ths  sscoed  Is  tat  'OB' 
coablnstiOB  of  ths  3  coivutsrs*  ths  third  string  Is  ss  'OB'  cosiblnstlon  of  ths  6  ssnsors.  Tsbls 
6  show*  ths  gsBsrstsd  trsnaltlon  tsbls  snd  slso  ths  rssldns  of  ststss.  Ths  39  conflgurstlons  srs 
unehsagsd  fron  tsbls  2»  ths  trsssltloo  tsbls  sntrlss  srs  sngasntsd  by  tbs  3  rspslr  Isrsls*  sad 
whsn  squlsslsnelng  Is  don*  It  Is  found  thst  thsr*  srs  non  2  sztrs  ststss.  This  Bodsl  esn  bs 
sxscutsd  using  ths  MPA  pseksgs  snd  ths  rslisbility  is  inprossd  by  eh*  introduction  of  s  rspslr 
policy. 

For  s  second  sltsrstion  1st  us  rstum  to  ths  stsndsrd  nodsl  snd  forgst  rspslr  consldsrstlons. 
Instssd  vs  shsll  suppose  thst  ssch  conputsr  Is  dusl-^rsdundsat  sad  la  thus  nsds  up  of  2 
sub'conputsrs  only  on*  of  vfalch  nssds  to  opsrst*  to  sllov  sn  output  fron  tbs  coaputsr  to  go  to 
ths  setustor.  Ths  dsslgn  infomstlon  Is  sltsrsd  by  ths  addition  of  3  sub-nods  Is  corresponding  to 
ths  sub-divlslon  of  ssch  conputsr.  Within  ths  nsv  suh-nodsls  ths  opsrstlonsl  logic  is  s  slapls 
'OB'  stsesnsnc  bstvsse  the  2  sub-conputsrs  and  thsrs  sxs  no  fault  propogstlon  offsets  within 
thsss  sub-nodsls.  The  top  level  sub-nodsl  rsnsins  unchanged.  Ths  fault  types  snd  detection 
nsthods  srs  extended  to  the  new  set  of  12  low-level  blocks  In  the  epproprlete  nsnasr.  end  the 
■ub-conputera  srs  all  dssnsd  to  bs  hsrdvsrs  squlvslsnt.  Table  7  shows  ths  first  6  lines  of  s 
transition  tsbls  which  sxtsnds  to  891  configurations*  snd  slso  ths  final  transition  tsbls  based 
on  38  working  ststss.  Just  s  slight  nodal  eonplsxity  has  produced  s  significantly  Incrssssd 
nodsl  but  presents  no  difficulties  for  the  BMC  psekag*. 

5  TOTAL  AHAtTSXS  SYSTEM  AHD  EXAMPLE  OF  APPLICATION  TO  A  CIVIL  TUBBOFAN  ENGIVE  COmtOL  SYSTEM 

Ths  operation  of  the  total  package  contains  various  data  files  snd  keyboard*  screen*  snd  printer 
poeslbilltlce  es  previously  described.  A  typical  'nlnlnun*  order  of  operation  of  ueer  selected 
activitiaa  Is  as  follows 

1)  Start  executing  BMC. 

2)  Esybosrd  entry  of  dsslgn  Infomstlon  data  sat. 

3)  Modal  gsnsrstlon. 

4)  Writs  out  to  s  transition  table  data  file* 

5)  Start  sxseutlng  MPA. 

6)  Bead  In  transition  table  data  file. 

7)  Keyboard  entry  of  fault  event  fsilur*  rstss. 

8)  Tina  slnulstlon. 

9)  Display  snd/or  print  snd/or  plot  probability  sod  reliability  data. 

There  ere  4  different  data  file  types  currently  svsllsble  within  the  package 
e)  Design  infomatlon  data  files. 

b)  Traneltion  table  data  files. 

c)  Markov  rslisbility  nodsl  dst*  files. 

d)  Stats  probsbllltlss  data  files. 

Thsss  files  reflect  ths  coMon  dsslrs  to  break  off  sod  rssuns  conpuCatlon  or  to  altar  tbs 
eonputstlon  fron  a  particular  point  without  in  either  csss  having  to  start  fron  the  beginning. 

For  instance*  It  nay  bs  dsslrsbls  to  conpsrs  different  policies  with  tbs  sans  dsslgn  essunptlons, 
or  it  nty  bs  dsslrsbls  to  run  a  eonplsts  nodsl  with  different  rspslr  tines  or  with  different 
failure  xstes  or  with  different  variables  tsbulstsd  or  plotted*  or  it  nay  bs  desirable  to  store 
stats  probsbllltlss  for  conputlng  to  a  longer  execution  tin*  wlcbout  the  need  for  repetition. 

Also  St  various  points  ths  data  Is  Inspectabls  and  sllovs  sltsrstluns  to  bs  nadt  until  the 
Inspected  data  la  what  night  bs  expected.  This  psekag*  is  now  used  to  detsmins  the  rslisbility 
of  a  dual-rsdundant  slsctronlc  control  systMi  of  a  civil  turbofan  angina. 

A  typical  civil  turhofsn  snglo*  is  nsds  up  of  a  no^sr  of  rotsting  shafts*  ssch  with  a  conprsssor 
end  turbine*  a  conbustlon  ebanbsr  for  fuel  entry  wd  bum*  snd  a  by-pass  lysten.  Ths  control 
systea  of  such  sn  angina  has  to  snsur*  that  tbs  si^ly  of  fuel  to  ths  conbustlon  chanbsr  la 
correct  taking  Into  sccovat  tbs  various  nsasurdbsats  thst  can  bs  tsksn  fron  ths  engine*  and  It 
has  slso  to  ensure  thst  ths  variable  gsonstry  of  the  sugins  Is  also  approprlstsly  controlled. 

Thus  such  a  aystsn  will  read  nsasursnsnta  fron  ths  snglM  vis  emnsduesrs*  tmnslets  chess 
nsasursnsnts  into  rcqulrsnsnt*  for  ths  coutrollsr  functloua*  snd  than  opsrsts  actuators  to 
trsnulats  ths  rsqnlrMsnts  into  physical  rosllty.  Such  nsssurcrasnCs  ss  esn  bs  nad*  typically 
ineluds  the  rotacioosl  ehsff  spe^s*  the  prsasors  sad  tsnpsrstur*  of  tbs  sir  flow  sc  various 
parts  of  ths  angina*  fssdbsck  nsasurs&snts  Indicating  ths  results  of  actuator  novsnsnt  such  ss 
fuel  flow  rats*  various  on/off  signals*  sad  s  nsssnransnt  thst  conveys  ths  pilots  wishes  for  tbs 
power  to  bs  dslivsrsd  by  tbs  angina. 
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Typlcally*  noMdsys,  cIm  costrol  caleulAtlosA  at*  doM  Wthia  «a  oo^board  eoaputar.  Also  not 
uBOSusl  aovsdsys  is  to  build  rsduadsscy  into  tbs  control  oystaa  by  havloc,  for  ozsaplo,  2 
Idontlcsl  loMO  of  oloctroBle  hsrdvaro,  osch  of  vbicb  Is  sopsrstoly  capsbU  of  oaglBo  control, 
sad  with  SD  tator-lsao  blcbosy  to  sllov  cross-cbssaol  cooMslcstlen  so  tbsc  it  Is  not  nocssssry 
to  chsago  SD  satire  Isas  for  oosry  fault.  Tbsso  2  idsatlcsl  Isass  eoatsla  circuits  sssoclstsd 
with  a  co^utsr.  Inputs,  outputs,  sad  power  simply.  Tbs  eeatrol  systM  is  known  to  bo  capable  of 
eeatsialat  to  opsrsts  if  it  bss  at  least  oao  of  oscb  fuactloa  within  the  dusl-rsduadsat  parts 
still  oparstlng,  and  If  tbs  latar-'laaa  bighw^  la  oparatiag  wbanavor  it  is  naodad  for  cross-laaa 
cowBunlcatloQ,  and  if  tbs  non-raduadsat  parts  assoclatod  with  actuators  arc  operating.  The  power 
supply  la  each  laaa  Is  Itself  dual-roduadsat  wltb  a  priaary  sad  secondary  soucce  cither  of  which 
can  operate  the  electrical  faaetioas  of  oaa  lane* 

Electrical  faults  haws  anch  potential  for  fault  propotetlon.  tfithln  the  aaalyaad  systaa  It  le 
known  that  total  power  to  one  lane  will  fail  all  the  inputs,  outputs,  and  eoaputar  of  that  lane, 
also  It  la  known  that  the  eoaputar  provides  a  clock  signal  to  certain  Inputs,  also  It  is  known 
that  certain  conditioning  circuits  cause  lose  of  aore  of  than  one  input  or  output.  Outside  the 
dual-roduadsat  parts  it  Is  known  that  csrtaln  input  functions  are  affected  by  coMon-aodo 
hardware  which  can  causa  loss  of  Input  to  each  elactronlc  lane,  also  It  la  known  that  aoas  faults 
salat  which  will  causa  total  ayatan  fallura  either  directly  or  through  fault  propogaclon  af facta. 

The  operational  logic  la  baaed  around  the  Information  ahovo  concerning  dual-radundant  hardware 
and  the  Intar-lana  highway  and  taking  the  fault  propogationa  Into  account.  Further  design 
Information  la  known  about  the  software  caleulationa  done  within  the  eomputar.  These 
calculatione  Inpllcltly  divide  the  Inputs  into  3  types 

e)  "Oon^t  care**  Inputs  which  are  not  used  In  the  control  caleulationa. 

b)  "Acconmodatad"  Inputs  which  era  used  for  primary  control  caleulationa  but  for  which  a  set  of 
back-np  ravaralonary  caleulationa  exist  if  tbeaa  li^ta  are  unavellable. 

c)  "Vital**  Ittpute  which  ere  used  for  primary  control  caleulationa  and  which  cannot  be 
eceoaMdated. 

The  ayetem  will  operate  e  **preferred*'  order  of  active  control  hardware.  Lane  A  hardware  le 
preferred  to  lane  S'e  wherever  it  is  available  and  cMiplate  lane  change  only  occurs  If  power  to 
lane  A  la  lost  or  If  laaa  A  and  the  Intar-lana  highway  are  both  faulty.  The  ayetan  will  aleo 
**prafer**  priaary  control  mods  to  ravaralonary  mods. 

The  repair  philosophy  la  raaaonably  aophlatlcated.  It  la  based  on  2  achednled  repair  levels  plus 
end-of-run  repair.  The  end-of-run  repair  criterion  la  that  if  power  Is  eonplately  lost  to  one 
lane  or  If  there  are  faults  In  any  Input  or  output  end  Intar-lene  highway  together  then  repair 
must  be  made  before  next  run  eoanencaa.  The  level  1  repair  covers  loss  of  either  power  supply  In 
either  lane  and  also  the  total  loss  of  any  Input  or  output  function.  The  level  2  repair  covers 
lose  of  any  Input  ox  output  or  the  intar-lanc  highway,  that  la  to  say  every  known  fault  is 
repaired  at  level  2. 

Many  faults  are  datactad  within  the  software  of  either  conputer  with  the  continuing  proviso  of 
Inter-lane  highway  operating  If  one  computer  la  to  detect  Input  or  output  falluraa  In  the  other 
lane.  Some  faults  are  detected  within  the  software  but  wltb  the  further  raqulrmsent  that  a 
croaa-chack  la  made  with  the  earns  Input  or  output  in  the  other  lane  which  than  also  naada  to  be 
operating.  Computer  end  power  supply  faults  are  all  raekonad  to  be  automatically  detected 
within  the  ayatam  hardware.  Soma  input  fanlta  are  actually  ballavad  to  be  undetectable  of  which 
such  faults  In  ''don't  care"  inputs  do  not  matter  but  others  would.  The  intsr-lene  highway 
failure  la  detected  by  either  computer  being  able  to  make  comparisons  between  the  inputs  end 
outputs  of  each  lane. 

The  equivalence  of  hardware  le  described  almply  In  that  the  dual-redundsnt  hardware  of  lane  B  le 
reckoned  to  be  exactly  Identical  to  that  of  lane  A.  The  dormant  logic  will  aaauma  that  no 
detection  capability  exlate  between  eyeten  rune. 

All  of  the  above  design  Information  guides  the  choice  of  block  structure  and  then  seta  the 
various  logic  Information  once  the  block  atructnra  is  aattled.  Tba  natural  block  etructura  to 
adopt  would  be  to  have  individual  blocks  for  each  input  and  output  and  conputer  and  pewer  source 
within  each  lane  and  for  each  non-radundant  function  also.  For  demonatratlon  purposes  this 
ersatss  too  many  blocks  to  be  readily  digested.  So  the  varioue  fonctlons  need  to  be  combined 
into  a  smaller  number  of  blocks,  which  builds  In  soew  consarvatlsm,  there  being  no  need  to  make 
the  aaalyala  any  more  conplex  if  this  la  achlavad. 

The  chosen  block  structure  baa  bean  to  create  a  top  level  of  16  blocks  of  which  there  are  6  In 
each  lane  covering  tba  "don't  care"  functions,  the  "accoesnodatad"  fuactlona,  the  "vital” 
functions,  the  'Hniltlpla"  fuactlona  (those  affecting  Miltlplc  Inputs  anu  outputs),  computer,  and 
power,  and  4  others  covering  rnnn  moite  "don't  care"  functions,  coMon-moda  "acconmodatad” 
fuactlona,  single  faults  causing  ayatam  failure,  and  the  intar-lana  highway.  The  power  auppllee 
are  then  split  into  2  aub^odala  each  with  2  blocks  which  cover  tba  altamatlvc  power  aoureaa. 
This  gives  a  total  of  18  low-'laval  blocks  and  tba  various  Information  relating  to  each  of  tbaaa 
low-laval  blocks  la  shown  on  table  8.  There  are  25  fault  evsnta  and  3  repair  events  to  be 
snalyssd  la  the  gansrstlon  process.  There  are  juet  15  failure  ratea  naadad  and  thasa  art  also 
given  OB  table  8«  Iha  fault  propogatlon  and  oparatlonal  logic  for  each  sub-modal  and  the 
ayatam-  wide  repair  policy  la  given  on  table  9. 

Am  aaalyala  la  carried  out  which  shows  tba  affect  of  variation  of  the  cenaarvatlva  assumption 
built  Into  tba  fault  count  limit.  Table  10  givaa  the  results  for  the  ntoibara  of  configurations. 
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wmhm  of  atatoot  ao4  total  ajataa  fallura  rataa  asalaat  tba  fault  count  Halt.  Tha  table  abowa 
that  uhaa  tha  fault  couat  lljdt  la  aat  at  1  chaa  euary  dafact  la  tha  ayataa  laada  to  total  ayataa 
fallura*  aad  that  vhan  tha  fault  count  lladt  la  ralaad  tha  total  ayataa  fallura  rata  dropa  and 
boaaa  la  onto  tha  rata  that  la  aehlaaahla  If  tha  fault  count  Halt  vaa  not  appllad.  Thla  la  aaan 
to  happaa  at  an  lacraaalac  coat  in  nu^ar  of  eoaflguzatlona*  but  tha  auabar  of  atataa  Incraaaaa 
flratly  aad  than  dropa  vary  rapidly.  Thla  lattar  affact  la  dua  to  tha  fact  that  ayataa 
aqulvalaacaa  irtiich  h^a  baaa  auppraaaad  by  aa  arbitrary  fault  couat  Halt  ara  now  bains  aaan. 
Tteaa  raaulta  aaauaa  a  ayataa-rua  (flight)  tiaa  of  tO  houra*  aad  repair  tlaaa  of  SO  aad  400 
hour a. 

da  aaalyala  la  alao  carried  out  to  ahou  tha  affact  of  vary las  tha  repair  tlaaa.  Table  11  glvaa 
tha  raaulta  of  auch  variatloaa  ualng  tba  fault  count  Halt  of  4.  It  can  ba  aaan  that  for  thla 
ayataa  and  thla  aaauaad  repair  poUcy  that  tha  variation  of  the  laral  2  repair  tlaa  la  aora 
algalflcaat  than  that  of  level  1.  Tha  raaulta  Include  tha  ultlaata  ayataa  fallura  rataa  aa  tha 
repair  tlaaa  ara  atratchad  to  infinity  ao  that  only  the  level  0  repair  la  atlll  carried  out. 

If  a  target  total  ayataa  fallura  rata  of  10  par  allHon  boura  la  required  than  clearly  tha  repair 
level  tlaaa  can  ba  picked  to  achieve  thla.  If  no  aatlafaetory  coablnatlon  of  repair  tlaaa  and 
ayataa  raliablllty  la  obtainable  than  it  la  nacaaaary  to  either  altar  tha  repair  policy  Itaalf, 
or  if  thla  la  not  aatlafaetory.  to  expand  the  daai^  Inforaation  data  aat  to  raaova  aora 
conaarvatlvanaaa  froa  It.  or  If  thla  doaan't  work  than  tha  daalgn  cannot  aaat  tha  raqulraaanta 
anywayl 

6  cotrcLOszoir 

A  general  phlloaophy  haa  bean  daaonatratad  whl^  haa  aa  Ita  ala  that  of  alialnatlng  arrora* 
oalaalona.  and  aaauaptlona  that  can  occur  within  a  reliability  analyala  of  fault-tolerant 
ayataaa.  It  haa  been  aaan  that  by  conaldaratlon  of  tha  affacta  of  aingla  faulta  on  ayataa 
conflguratlona  rather  than  by  conaldarlng  fault  aata  or  aaquaneaa  that  thaaa  problana  ara 
aenawhat  reduced  and  can  ba  allalnatad  altogether.  A  concept  haa  bean  davlaad  which  aaaka  to 
focua  tha  reliability  anglnaara  wind  in  auch  a  way  that  all  faulta  within  a  ayataa  ara  at  laaat 
conaldarad,  and  In  a  way  that  can  ba  cloaaly  linked  to  tha  ayataa  daalgn  aaauaptlona  and  checked 
froa  tha  ?M£A.  It  la  alao  carried  out  in  a  way  that  anaurea  ovareatlaatlon.  rather  than 
undaraatlaatlon.  of  tha  total  ayataa  fallura  rata  while  tha  daalgn  aaauaptlona  ara  being 
foraulatad.  It  haa  baaa  ahown  that  tha  procaaa  of  reliability  analyala  can  than  ba  autoaatad 
right  through  to  tha  final  raaulta.  and  a  packi^a  llluatratad  which  la  uaar-lntaractiva  for 
flexible  naalpulatloR  of  tha  analyala  or  the  output  froa  It.  Tha  procaaa  aa  danonatratad  la  vary 
thorough  In  Ita  traataant  of  tha  faulta  within  tha  ayatan.  There  la  further  potential  for  uaa  or 
devalopnant  of  ■athanatlcal  raaulta  in  order  to  aixplify  or  apaad  up  tba  calculatlona. 
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APPEMDU  A  MAIKOV  MATHEMATICS 


Th«  basic  atata^flow  Markov  aquation  is  givan  by 


vfaara  P  (t)  -  (PI  (t),  P2  (t),  . .  Pn  (t))*  (2 

Tbs  solution  of  equation  (1)  is  givan  by  (rafsrancs  S) 

L  Q  <‘3 

P  (t)  -  •  “  .  £*  (o)  {3 

where  (o)  is  the  state  probability  vector  at  the  start  of  the  systen  run.  We  nay  define 


W  (o,  t)  -  e  (4) 

and  substituting  into  (3)  gives 

P  (t)  -  W  (o.  t)  .  r*  (o)  (5) 

let  us  suppose*  for  conceptual  ease  only*  that  Q(t)  is  a  constant  natrix  Q  so  that  U  (o*  t)  becomes 
W  (t).  Then  suppose  also*  again  for  conceptual  ease  only*  that  each  system  run  Is  of  constant 
duration  so  that  (S)  may  be  generalised  as 

P  (m.f)  -  W  (f)  .  P*  ((m  -  l).f)  m  >  1  (6) 

The  relationship  betveen  P,*  (m.f)  (state  probabilities  at  start  of  run  m4-l)  to  P  (m.f)  (state 
probabilities  at  end  of  run  m)  is  determined  by  the  repair  (if  any)  which  is  carried  out  between  the  2 
runs  and  by  any  other  between-runs  effect*  e.g.  detection  of  unknown  faults*  that  can  occur  between 
runs.  In  general  there  are  some  discrete  transfers  of  probability  at  such  tines  that  can  be  expressed 
as  a  linear  transformation  given  by 

P*  (m.f)  -  Ro.  P  (m.f)  n  ^  1  (7) 

«diers  Ro  will  usually  contain  O's  and  l*s  only*  the  exception  being  in  systems  where  probabilistic 
events  occur  between  system  runs.  If  we  now  aeeume  that  in  addition  to  the  end-of>run  repair 
transitions  there  are  also  k  further  repair  levels  that  the  systen  is  operated  to  at  various  scheduled 
Intervals  Tl*  1  •  1  to  k,  then  these  are  expressed  as 

P*  (m.Tl)  -  Ri.  P  (m.Tl)  1  -  I  to  k,  m  >  1  (8) 

again  assuming  constant  repair  Intervals.  Row  let  us  suppose*  for  conceptual  esse  only,  that  the 
rcpelr  level  time  interval  Is  made  of  exactly  M^  runs  of  duration  f.  Then  combining  equationa  (6), 
(7)*  (8)  appropriately  glves^ 

P*  (b.Tj)  -  Rj.WCfj.CRo.WCf))"'"*.?*  ((b-U.TI)  >>1  (9) 

Row  if  we  define 

-  W(f) 

W^'^Tl)  -  RI.W(f).W^®^(f)”‘*‘ 

then  substituting  (10)  into  (6)*  (7)  snd  (9)  gives 

P*  (».f)  -  P*  ((B-U.f) 

■■  ■  >  X  (U) 

P*  (■.«)  -  w'  ■'(Tl),  P»((»-1).TI) 

Clsarly  (11)  suggests  s  genersllsstlon  to  the  known  k  levels  of  repsir  snd  this  Is  evaluated  as 


W**’  (f)  -  Rl.  W(f), 

P*  (■.II)  -  W^^-^di).  P*((«-l).Tl) 


1  -  I  to  fc.  ■  >  1 


assuming  that  each  higher  repair  lavel  Intarval  Ti  is  a  multiple  Ml  of  the  next  loveat  repair  level 
Interval  Tl-l.  Putting  i  •  k  into  (12)  then  gives  the  relationship  of  the  state  probabilities  at  the 
start  of  aach  tlma  parlod  Tk  to  ths  state  probabilities  at  ths  start  of  ths  prsvious  period  of  like 
duration.  Equations  (12)  can  be  built  up  theoretically  and  dapending  on  the  nature  of  the  auttrlccs  Q» 
Ri*  1  •  0  to  k,  may  yiald  aubatantlal  elmplificatlon  due  to  the  spareeness  of  the  matricaa  and 
particularly  if  any  of  tha  Ri*  1  •  0  to  k*  hava  almple  patterns  of  I's  and  O's.  If  for  instance  at 
tims  Tk  it  is  known  that  all  faults  are  repaired  thM  Rk  bae  a  top  row  of  I's  snd  the  rest  O's  which 
when  substltutsd  in  (12)  givas  the  lapedlste  result  that 

£*  (m.Tk)  -  (I*  0 . 0)  m  >  I  (13) 

which  maana  that  the  probabilistic  datsminatlon  of  the  system  is  repeated  for  all  such  time 
intarvala. 
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for  m  r*ll«blllty  «a«l79l«  wo  moy  ooBumo  thftc  th«  total  ayatM  fallura  atata  la  atata  nuabar  n. 
Aaaualag  that  thla  la  a  "trapping"  atata,  and  that  Fn*((»-l}.f)  >  0  (ayataa  run  doaa  not  start  in  this 
atata)  than  Pn  (n.f)  la  tha  probability  of  ayatan  failura  during  thla  run  and  tba  ayataa  rallabillty 
calculation  baconaa 


M 

(2: 

■-1 


Pn  (..fjJ/Cm.P) 


(U) 


wbara  M  la  a  apaclflad  nunbar  of  runs.  If  it  la  cot  tha  caaa  that  Pn*  ((■-D.f)  •  0  than  (14)  la 
aaandcd  to  raaova  tba  probability  of  starting  a  run  vlth  ayatan  in  tha  failed  atata,  tha  failura 
having  occurred  in  a  previous  tun,  and  la  given  by 

M 

t  -  (^(Pn  (m.t)  -  Po»  (15) 


and  nany  of  tha  tana  of  (15)  usually  cancel  out  to  leave  a  fora  of  equation  (14)  baaed  on  a  repair 
Interval  rather  than  on  the  ayatan  run  tine  f.  If  state  n  does  not  trap  then  (14),  (15)  bacons  sore 
coBplex  but  even  so  the  Inforaation  In  the  natrlcea  Q,  Ri,  1  *  0  to  k,  nay  point  the  way  to  tha  right 
expression. 

The  renalnlng  Issue  Is  choice  of  M.  If  equation  (13)  holds  good  then  tha  choice  of  M  la  slnply  Tk/f. 
If  there  la  no  tine  at  which  It  la  known  that  repair  la  guaranteed  then  M  la  less  readily  defined. 
However  aa  n  Increases  the  solution  to  equations  (12)  reaches  s  steady  state  solution  defined  by 

p<  .  (Tk).  P'  (16) 

The  solution  to  (16)  could  be  found  by  the  elgan-value  eigen-vector  nethod  and  then  Is  used  instead 
of  (o)  in  (12)  than  the  state  probabilities  would  again  be  repeatable  and  M  can  be  set  to  Tk/f. 

Aa  an  ezanple  take  a  alnple  2-boz  'either  or*  ayatan  giving  rise  to  4  states.  If  the  systen  la  failed 
when  both  boxes  are  faulty  then  Q  bacoSMS 


0  -  (- 

•rl  • 

■r2 

0 

0 

0 

) 

( 

) 

( 

rl 

-r2 

0 

0 

) 

( 

)  d?) 

< 

r2 

0 

-rl 

0 

) 

( 

) 

< 

0 

r2 

rl 

0 

) 

Tb.  r.p.lr  policy 

states 

that 

at  the 

end  o£  ..cb  nib  only  set.  6  (sy.tM  f.ilur.)  t.  r.pslr.d 

Is  glv.n  by 

»o  -  ( 

1 

0 

0 

1 ) 

< 

) 

( 

0 

1 

0 

0  ) 

( 

) 

(IS) 

( 

0 

0 

1 

0  ) 

( 

) 

( 

0 

0 

0 

0  ) 

Substituting  (17)  snd  (18)  Into  (3)  and  (7)  and  then  substituting  (7)  Into  (3)* gives  the  rscursive 
relationships  for  the  and-of-run  state  probabilities 

pi(«.f)  -  (pi((»-i).f)  +  p*((»-i).f)).. 

P2(«.£)  -  P2((»-l).f)«  +  (Pl((»-l).f)  +  P4((«-I).£))(."’^^*-.''''‘'^^’^) 

P3(«.f)  -  P3((»-l).f).  +  (Pl((»-I).f)  +  P*((»-l).f))(.‘*‘*-.‘^'*'^^^*) 

P6(«.f)  -  P2((»-l).f).  +  P3((«-l)f)(l-.‘'^*^ 

+  (Pl((»-l).f)  +  P*((»-l).f))(I-.‘'^‘*)(l-.‘^^‘) 

The  steady  state  solution  of  (19)  la  given  by 
PI'  - 

P2'  -  (l-.'*‘*)>/D 

P3'  -  (l-.''^')’/D  (20) 

P4'  -  (1-.  **‘*)  d-."'^*')  d-.*'*  * 

n  .  1  .  3,-(rl  +  p2)<  +  ,-(2  +  r2)t  ^-(rl  +  2  rt)f 


where 
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Th*  lov>ord«r  «pproxlMtloB«  of  <20)  for  tbo  ajntmm  rolloblllfcy 

r  -  P4*/f  »  rlr2(rl  +  r2)/(rl*  +  rlr2  +  r2*)  (21) 

which  eoul^  not  b«  obtalaod  hy  tho  fault  tr««  Mthod,  Altaratloft  of  th«  ropalr  policy  of  oven  this 
•Iflplo  aodtl  ylolda  other  such  Intorooting  rooulta. 

APPENDIX  B.  MPA  EXECUTION  PBZNT-OUT. 

**********  Hodol  infotMtion.  ********** 

Thore  are  9  states 

There  are  2  basic  rates  with  values  0.2000B-04  O.lOOOE-03 


States 

Multiples 

of  basic  rates 

f  roa 

to 

(1) 

(2) 

1 

2 

6 

0 

1 

3 

0 

3 

2 

3 

1 

1 

2 

4 

2 

0 

2 

S 

1 

0 

2 

6 

1 

0 

2 

1 

0 

1 

2 

9 

0 

1 

3 

7 

2 

0 

3 

9 

2 

2 

4 

7 

1 

X 

4 

6 

1 

0 

4 

9 

2 

2 

5 

7 

2 

2 

5 

9 

2 

1 

6 

9 

4 

3 

7 

9 

3 

2 

8 

9 

3 

3 

**********  operating  Conditions  Inforsation.  ********** 

There  are  9  states  with  initial  values  >> 

I. 0000  0.0000  0.0000  0.0000  0.0000  0.0000  0.0000  0.0000  0.0000 

The  nuaber  of  maintenance  types  is  I  •> 

Maintenance  type  1  at  0.0000  hours  to  states  •> 
1234S6781 

Run  tiae  •  100.0000  Flight  tiae  «  12.0000  Display  interval  •  111.0000 

Tiae  step  •  0.1000  Initial  cycles  •  1  Ongoing  cycles  «  1  Factor  •  1.0000 

Nuaber  of  systea  reliability  ihforaation  points  is  0 

******«**«  Output  Specification  Inforaatlon.  ********** 


There  are 

3 

outputs  froa 

9  states 

-> 

Output 

1 

contains  1 

states  -> 

1 

Output 

2 

contains  7 

states  -> 

2  3 

4 

5  6 

7 

8 

Output 

3 

contains  1 

states  -> 

9 

Nuaber  of  outputs  on  graphics  plot  is  2  ->  23 

List,  plot,  result  indicators  are  ->111 


X-axls  exponential  grid  <-l  0  1>  and  Y-axis  <-l  0  I> 

Nuaber  of  increaents  on  linear  axes  is  ->  5  S 

Scales  of  3  outputs  on  linear  plot  are  ->  1.000  0.50C0E-01  O.lOOOE-03 

Line  trace  patterns  for  3  outputs  are  ->  FFFF  ffff  FFOO 

**********  Tabulated  Probability  Data.  ********** 


TIm. 

Outputs. 

(1) 

(2) 

(3) 

0.000 

1.000 

O.OOOOB.OO 

0.00008.00 

12.000 

0.9950 

0.5021E-02 

0.59848-05 

24.000 

0.9900 

0.10018-01 

0.18008-04 

36.000 

0.9850 

0.14958-01 

0.29938-04 

48.000 

0.9801 

0.19868-01 

0.41768-04 

60.000 

0.9752 

0.24748-01 

0.53558-04 

72.000 

0.9704 

0.29588-01 

0.65248-04 
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84.000 

0.9655  0.34388-01  0.76848-04 

96.000 

0.9608  0.39148-01  0.88378-04 

•  Sy«tM  IMllablllty  D«t«. 

SystM  opacstlon  tlM  !■  ->  99.9999 

bveiag*  «y(t*«  tuft  probablllttas  -> 

0.9777  0.22218-01  0.47468-04 

Average  ratea  of  total  syatea  failure  -> 

0.81488-01  0.10518-02  0.39558-05 

Average  deapatch  probabilitiea  -; 

0.9803  0.19748-01  O.OOOOE-iOO 

Average  repair  probability  and  rate  -> 
0.47468-04  0.39558-05 

Average  deatlnation  repair  probabilitiea  -> 

1.000 

**»•»*•»•*  End  of  print-out.  *»»•*••**» 


fie-uar  1.  ReftiLtrKt  Z.  jrsren.  A*.CHiT»c-ruae. 


Xr,+2r, 


Ft&uae  Z. 


* 


RraearNCr  2  SrSTfrt.  State  ToAtisiTioHS. 
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TABLE  1.  RErERBNCE  2  SYSTEM.  STATES  DESCRIPTION. 

itate  State 
Njmber.  description. 


1 

Everything  working. 

V 

-3-i  o 

o  o 

o 

o 

O 

0 

o 

?. 

One  sensor  failed. 

tv 

— 5’rv— 3 

0  O 

o 

o 

o 

Q 

p 

2 

3 

One  computer  failed. 

I', 

3r» 

r,  ♦  r, 

O 

o 

o 

O 

0 

o 

fi 

4 

2  dissimilar  sensors  failed. 

K 

O 

Xr. 

O  O 

o 

O 

o 

o 

P. 

5 

remaining  ones  dissimilar. 

2  dissimilar  sensors  failed. 

h 

o 

r; 

0  O 

0 

1 

0 

o 

o 

P. 

remaining  ones  similar. 

6 

2  similar  sensors  failed. 

h 

o 

r, 

O  0 

o 

o 

o 

p. 

7 

one  sensor  and  computer  failed. 

f. 

o 

2r,  o 

1 

0 

o 

p> 

8 

3  dissimilar  sensors  failed. 

p. 

o 

O 

0  n 

o 

o 

o 

-3r, 

P. 

9 

Total  system  failure. 

f. 

o 

'"i 

If,  j-Vrv 

IV 

TABLE  2.  REFERENCE  2  SYSTEM.  MANUAL  TRANSITION  TABLE. 


Configuration  Single  failures  of 

either  a 

sensor 

or 

a  computer. 

nuai>er  description. 

XA 

XB 

X 

YB 

YC 

Y 

ZA 

ZC 

Z 

1 

Everything  working. 

2 

3 

4 

5 

6 

7 

8 

9 

10 

2 

Sensor  XA  failed. 

11 

4 

12 

13 

14 

15 

16 

X 

3 

Sensor  XB  failed. 

li 

. 

4 

17 

16 

X 

19 

20 

21 

4 

Computer  X  failed. 

. 

. 

X 

22 

X 

X 

23 

X 

5 

Sensor  YB  failed. 

12 

17 

X 

24 

7 

25 

26 

27 

6 

Sensor  YC  failed. 

13 

18 

22 

24 

7 

28 

29 

X 

7 

Computer  Y  failed. 

14 

X 

X 

30 

30 

X 

X 

8 

Sensor  ZA  failed. 

15 

19 

X 

25 

28 

31 

10 

9 

Sensor  ZC  failed. 

16 

20 

23 

26 

29 

X 

3i 

10 

10 

Computer  Z  failed. 

X 

21 

X 

27 

X 

X 

33 

11 

Sensors  XA,XB  failed. 

4 

X 

32 

X 

X 

X 

12 

Sensors  XA,YB  failed. 

. 

X 

X 

34 

14 

X 

35 

X 

13 

Sensors  XA.YC  failed. 

32 

22 

34 

14 

X 

X 

X 

14 

Sensor  XA, 

computer  Y  failed. 

X 

X 

♦ 

X 

X 

X 

15 

Sensors  XA,ZA  failed. 

X 

X 

X 

X 

X 

X 

X 

16 

Sensors  XA,ZC  failed. 

33 

23 

35 

X 

X 

X 

X 

17 

Sensors  X8,YB  failed. 

X 

. 

X 

X 

X 

X 

X 

X 

18 

Sensors  XB,YC  failed. 

32 

. 

22 

X 

X 

36 

X 

X 

19 

Sensors  XB,ZA  failed. 

X 

. 

X 

X 

36 

X 

37 

21 

20 

Sensors  XB,ZC  failed. 

33 

. 

23 

X 

X 

X 

37 

21 

21 

Sensor  X6, 

computer  Z  failed. 

X 

X 

X 

X 

X 

22 

Sensor  YC, 

computer  X  failed. 

X 

X 

X 

X 

X 

23 

Sensor  ZC, 

computer  X  failed. 

X 

X 

X 

X 

X 

24 

Sensors  YB,YC  failed. 

34 

X 

X 

38 

7 

38 

X 

X 

25 

Sensors  YB,ZA  failed. 

X 

X 

X 

30 

39 

27 

26 

Sensors  YB,ZC  failed. 

35 

X 

X 

. 

X 

X 

39 

27 

27 

Sensor  YB, 

computer  Z  failed. 

X 

X 

X 

36 

X 

X 

28 

Sensors  YC,ZA  failed. 

X 

36 

X 

30 

X 

X 

29 

Sensors  YC,ZC  failed. 

X 

X 

X 

X 

. 

X 

X 

X 

30 

Sensor  ZA, 

computer  Y  failed. 

X 

X 

X 

39 

X 

X 

31 

Sensors  ZA,ZC  failed. 

X 

37 

X 

X 

X 

10 

32 

Sensors  XA,XB,YC  failed. 

22 

X 

X 

X 

X 

X 

33 

Sensors  XA,XB,ZC  failed. 

. 

. 

23 

X 

X 

X 

X 

X 

34 

Sensors  XA,YB,YC  failed. 

X 

X 

14 

X 

X 

X 

35 

Sensors  XA,YB,ZC  failed. 

X 

X 

. 

X 

X 

X 

X 

36 

Sensors  X8,YC,ZA  failed. 

X 

X 

X 

X 

X 

X 

37 

Sensors  XB,ZA,ZC  failed. 

X 

. 

X 

X 

X 

X 

21 

38 

Sensors  Y8,YC,ZA  failed. 

X 

X 

X 

30 

X 

X 

39 

Sensors  YB,ZA,ZC  failed. 

X 

X 

X 

X 

X 

27 

TABLE  3.  REFERENCE  2 

SYSTEM.  RESIDUE 

or 

STATES 

AND 

TRANSITIONS 

State  (Configurations) 


Single  failure  of 
sensor 


/  one  computer. 


1  (1) 

2  (2, 3, 5,6, 8, 9) 

3  (4, 7, 10, 11,24,31) 

4  (12,16,18,19,26,28) 

5  (13,20.25) 

6  (15,17,29) 

7  (14,21,22,23,27,30,32,33, 

8  (35,36) 


2  2  2  2  2 

3  4  4  5  6 

7  7  X  X  . 

7  8  X  X  . 

7  7  X  X  . 

X  X  X  X  . 

,37,38,39)  X  X  X  .  . 

XXX.. 


2 


3  13 

3  7  X 

X  X 

7  X  X 

7  7  X 

XXX 
X  X 

XXX 
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TABLE 

4. 

REFERENCE  2 

SYSTEM. 

BLOCKS  AND  ASSOCIATED  DATA. 

Description/Mnemonic , 

Fault  event 

During- 

Equivalence 

.  Prior-to- 

Fault 

number. 

run 

run 

count . 

detection. 

detection. 

Sensor 

XA 

1 

X 

No 

0 

Sensor 

KB 

2 

X 

XA 

No 

0 

Computer 

X 

3 

X 

- 

No 

0 

Sensor 

YB 

4 

Y 

XA 

No 

0 

Sensor 

YC 

5 

Y 

XA 

No 

0 

Computer 

y 

6 

Y 

X 

No 

0 

Sensor 

2A 

7 

Z 

XA 

No 

0 

Sensor 

2C 

8 

Z 

XA 

No 

0 

Computer 

Z 

9 

Z 

X 

No 

0 

TABLE 

5. 

REFERENCE  2 

SYSTEM. 

PROPOGATION  AND 

OPERATIONAL  LOGIC. 

Logic  string  of  faults 

causing  propogation. 

R  or  I. 

Blocks  affected 

X 

R 

XA  and 

XB 

Y 

R 

YB  and 

YC 

Z 

R 

ZA  and 

zc 

Operational  logic  string  £or  model. 

( (XA+ZA) . (XB+YB) . ( YC+ZC) )+(XA.ZA.XB.YB)+(XA.ZA. YC.2C)+{XB. YB.YC.ZC) 


TABLE  6.  REFERENCE  2  SYSTEH  PLUS  REPAIR.  TRANSITION  TABLE. 

Configuration  Fault  event  number  Repair 

number( failed  blocks).  and  mnenomic.  level. 

123456789012 
(XA)(XB)  <X)(YB)(YC)  (Y)(ZA)(2C>  (Z) 

1(  )  23456789  10  ... 

2  (C  )  .  11  4  12  13  14  15  16  XXX  ..  1 

3  (  C  )  11  .  4  17  18  XXX  19  20  21  .  .  1 

4  (CCC  )  ...  XXX  22  XXX  XXX  23  XXX  .  1  1 


39  )  C  CC  )  XXX  XXX  XXX  .  XXX  XXX  .  .  27  .  .  1 


Stat« 
numbe  r . 


1 

2 

3 

4 

5 

6 
7 

e 

9 

10 


Equlvalenced  fault  event  Repair 

number*  level. 

<  lto6  ><7to9>0  1  2 

(One  sensor)  (One  computer) 

222222333. 

<  5  5  6  7  .  3  8  XXX  1 

8  8  XXX  XXX  .  XXX  XXX  ..11 

9  9  XXX  XXX  .  3  XXX  XXX  1 

9  10  XXX  XXX  8  XXX  XXX  1 

9  9  XXX  XXX  ..  8  8  XXX  1 

XXXXXXXXXXXX  .XXXXXXXXX  1 

XXX  XXX  XXX  .  XXX  XXX  ..11 

XXX  XXX  XXX  ...  8  XXX  XXX  1 

XXX  XXX  XXX  .  XXX  XXX  XXX  1 


TABLE  7.  REFERENCE  2  SYSTEM  NITB  DUAL  COMPUTERS.  TRANSITION  TABLE. 

Configuration  Fault  event  number 

number(falled  blocks).  and  mnenomic. 

123456789  10  11  12 

(XA)(XB)(Xl)(X2)(YB)(YC)(Yl)(y2)(ZA) •ZC)(Z1)(Z2) 


1 

( 

)  2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

13 

2 

(C 

14 

15 

16 

17 

IS 

19 

20 

21 

22 

23 

24 

3 

(  c 

)  14 

25 

26 

27 

28 

29 

30 

31 

32 

33 

34 

4 

(  c 

)  IS 

25 

35 

36 

37 

38 

39 

40 

41 

42 

43 

5 

(  c 

)  16 

26 

35 

. 

44 

45 

46 

47 

48 

49 

SO 

51 

6 

{  c 

)  17 

27 

36 

44 

52 

53 

54 

55 

56 

57 

58 

7 

(  c 

)  18 

26 

37 

45 

52 

59 

60 

61 

62 

63 

64 

8 

(  C 

)  19 

29 

36 

46 

S3 

59 

65 

C6 

67 

68 

69 
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State 

Eauivalenced  fault  event 

nuflber 

number. 

< 

3 

to 

$  > 

< 

7  to 

12 

> 

(One  sensor) 

(One  computer) 

1 

2 

2 

2 

2  2  2 

3  3 

3 

3 

3 

3 

2 

4 

5 

5 

6  7 

8  8 

9 

9 

10 

10 

3 

8 

8 

9 

9  10  10 

4  11 

11 

11 

11 

4 

12 

12 

XXX 

XXX 

13  13 

13 

13 

S 

12 

14 

XXX 

XXX 

15  15 

15 

15 

16 

16 

6 

12 

12 

XXX 

XXX 

17  17 

17 

17 

16 

16 

7 

XXX 

XXX 

XXX 

XXX 

19  19 

19 

19 

19 

19 

a 

4 

15 

17 

19  16 

4  20 

20 

21 

21 

9 

13 

15 

)7 

19  16 

12  20 

20 

22 

22 

10 

13 

15 

15 

19  18 

21  21 

22 

22 

XXX 

11 

20 

20 

21 

21  22  22 

13  13 

23 

23 

12 

XXX 

XXX 

XXX 

... 

24  24 

24 

24 

13 

24 

24 

XXX 

XXX 

25  25 

XXX 

14 

XXX 

XXX 

XXX 

... 

26  26 

26 

26 

26 

26 

15 

24 

26 

XXX 

XXX 

27  27 

28 

28 

XXX 

16 

12 

26* 

XXX 

XXX 

12  27 

27 

27 

27 

17 

12 

24 

XXX 

XXX 

12  29 

29 

30 

30 

18 

24 

24 

XXX 

XXX 

30  30 

30 

30 

XXX 

19 

XXX 

XXX 

XXX 

XXX 

31  31 

31 

31 

XXX 

20 

13 

27 

27 

29  31 

13  24 

32 

32 

21 

13 

27 

26 

30  31 

13  32 

32  XXX 

22 

25 

27 

28 

30  31 

24  32 

32  XXX 

23 

32 

32 

32 

32  32  32 

25  2S 

25 

. 

24 

XXX 

XXX 

XXX 

... 

33  33 

XXX 

25 

33 

33 

XXX 

XXX 

XXX  XXX 

26 

XXX 

XXX 

XXX 

•  «  « 

34  34 

34 

34 

XXX 

27 

24 

34 

XXX 

XXX 

24  3S 

35  XXX 

28 

33 

34 

XXX 

XXX 

35  35 

XXX  XXX 

29 

24 

24 

XXX 

XXX 

24  24 

36 

36 

30 

24 

33 

XXX 

XXX 

24  36 

36  XXX 

31 

XXX 

XXX 

XXX 

XXX 

37  37 

XXX  XXX 

32 

25 

35 

35 

36  37 

25  33 

XXX 

33 

XXX 

XXX 

XXX 

... 

XXX  XXX 

, 

34 

XXX 

XXX 

XXX 

38  38 

XXX  XXX 

35 

33 

36 

XXX 

XXX  *  ! 

33  XXX 

XXX 

, 

36 

33 

33 

XXX 

XXX 

33  33 

XXX 

37 

XXX 

XXX 

XXX 

XXX 

XXX  XXX 

XXX 

, 

38 

XXX 

XXX 

XXX 

. 

XXX  XXX 

XXX 

* 

TABLE  8. 

ENGINE 

CONTSOL  SVSTBH. 

BLOCKS 

AND  ASSOCIATED  DATA. 

Descriptlon/llneaonlc 

Fault  event 

During^ 

Equivalence 

Prlor-to- 

Fault 

number 

run 

oc  cate  pec 

run 

count. 

detection. 

Billion  iioucs. 

detection. 

Lane  A 

•don't  care" 

AD 

1 

• 

R  -20.0 

No 

1 

functions. 

2 

AC.(BC.IH) 

R  -60.0 

No 

1 

Lane  A 

"accomodated" 

AA 

3 

(AC.BC).IB.BA  R  .10.0 

No 

1 

functions. 

4 

AC-^CBCalB) 

B  -30.0 

No 

1 

Lane  A 

'vital' 

AV 

5 

AC'fCBC.ZH) 

R  -40.0 

No 

1 

functions. 

Lane  A 

'mltipla' 

AH 

6 

- 

R  • 

1.0 

No 

1 

functions. 

7 

AC^(BC.IB) 

R  - 

9.0 

No 

1 

Lane  A 

computer. 

AC 

8 

AC 

R  -30.0 

No 

1 

Lane  A 

power . 

AP 

< 

Not  applicable 

> 

Lane  A  primary 

AP/P 

9 

AP/P 

R  -100.0 

No 

1 

Lana  A  secondary  At/s 

10 

AP/S 

R  -70.0 

No 

1 

power. 

Lane  B 

"don't  coca" 

BD 

11 

_ 

B  - 

MXl) 

NO 

1 

functions. 

12 

BC+(AC.ZB} 

B  - 

AD(2) 

No 

1 

Lana  B 

"accomodated” 

BA 

13 

(BC"fAC}.ZH.AA  B  - 

AA(3) 

No 

1 

functions. 

14 

BC^CAC.IB) 

B  - 

AA(4) 

No 

1 

Lana  B 

"vital" 

BV 

15 

BC4^(AC.IH) 

B  - 

AV(5) 

No 

1 

functions. 

Lane  B 

"Bultiple" 

BH 

16 

B  - 

AH(6) 

No 

1 

functions. 

17 

BC4(AC.IR) 

B  - 

AN(7) 

No 

1 

Lana  B 

computer. 

BC 

16 

BC 

B  - 

AC(8) 

No 

1 

34-23 


L«n€  B  power.  BP  <  Not  applicable  > 


Lane  B  priaary 

BP/P 

19 

BP/P 

E 

-AP/P(9) 

No 

1 

power. 

Lane  B  secondary 

BP/8 

20 

BP/8 

E 

-AP/8(10) 

No 

1 

power. 

Coaaon-Bod*  'don't 

CD 

21 

AC'fBC 

R 

-20.0 

No 

1 

care"  functions. 

Coaaoa^aode  "accoao- 

■  CA 

22 

R 

-  1.0 

No 

1 

dated*  functions. 

23 

AC.BC 

R 

-19.0 

No 

1 

Single  fault  causes. 

8 

24 

- 

R 

-  3.0 

No 

1 

Inter-lane  highway. 

IB 

25 

(AC.BC).((AO.BO). 
(AA.BA).(AV.BV)  ) 

R 

-17.0 

No 

1 

TABLE  9.  ENGINE  CONTROL  SYSTEM.  PROPOGATION  AND  OPERATIONAL  LOGIC. 

1)  Top  level  eub-aodel. 

Logie  ctring  of  faults  causing  propogatlon. 

S 
CD 
CA 
AC 

AD.AA.AV 
AM 
AP 
BC 

BD.BA.BV 
BN 
BP 

AO.BD 
AA.BA 

Operational  logic  string  for  sub-aodel. 

(AC.AA.AV)4(  (AC4-BC)  .(AA4BA-*>AV4BV).(AV4'BV}  .IH)<f(AC.AV)<f(BC.BA.BV)-f(BC.BV) 


Blocks  affected. 


AP  and  BP 
AD  and  BD 
AA  and  BA 
AA  and  AV 
AM 

AD,  AA,  AV 
AD,AA,AV,AM,AC 
BA  and  BV 
BH 

BD,  BA,  BV 
BD,BA,BV,BH,BC 
CD 

CA 


2)  Lane  A  power  sub^aodel*  1)  Lane  B  power  sub-aodel. 

No  fault  propogatlon  effects.  No  fault  propogatlon  effects. 

Operational  logic  string  for  sub-aodel.  Operational  logic  string  for  sub>aodel. 

P  +  S  P  +  S 

TAF  ,E  10.  ENGINE  CONTROL  SYSTEM.  FAULT  COUNT,  CONFIGURATIONS,  STATES. 

Systea  failure 

Fault  Count.  Configurations.  States,  rate  per 


aillion  hours 

1 

1 

1 

800.00 

2 

21 

13 

89.33 

3 

168 

68 

11.87 

4 

706 

281 

7.87 

5 

1797 

828 

7.76 

6 

3069 

1670 

7 

3929 

2303 

6 

4265 

2017 

9 

4329 

1395 

10 

4329 

439 

11 

4329 

439 

12 

4329 

439 

7.74 

TABLI 

!  11.  ENGINE 

CONTROL  SYSTEM, 

.  EFFECT  OF  VARIATION 

OF  REPAIR  TIMES. 

Repal r 

tiae  for  level 

2  repair  in 

hours. 

0  100 

200  300 

400  500 

600 

700 

800 

0 

5.21  5.65 

6.53  7.23 

7.84  8.46 

9.26 

9.72 

10.40 

34.38 

Repair 

tiae 

for 

SO 

5.50  5.86 

6.56  7.25 

7,87  8.50 

9.32 

9.78 

10.48 

34.75 

level 

1 

X 

repair 

150 

6.30  6.30 

6.60  7.35 

7.95  8.59 

9.48 

9.92 

10.65 

35.72 

in 

hours. 

as 

level 

2. 

5.21  5.89 

6.69  7.57 

8.45  9.43 

10.98 

11.63 

13.47 

47.10 

i 
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floftlMT*  SclMOM  Ltd 
f«nboroa^ 
Sttiptfhir* 

QOU  8Bfl 
ORit«d  KiO^dOS 


During  thn  purlod  t980^4  8oft«Mr«  8el«ne««  ntnff,  tog»th*r  irlth  DK  MOO  runenrch  sclnntlnt*/  built  and 
danonstratud  «  r«al-tiM  dlatrlbutad  ralatlonal  databa—  ayatau  naaad  ADDM,  which  ran  at  up  to  50  trans«- 
action#  par  aacond  on  a  network  of  Id^blt  alAi'^eoaipatarB*  Slaca  thaor  tha  oo^any  haa  aabarkad  on  a 
prlwata  aantora  dawalopaMnt  to  acala  up  tha  throughput  to  owar  1000  tranaactiona  par  aacond* 

Ihia  dawaXopaant  haa  raquirad  tha  adoption  of  a  highly  parallal  procaaaing  architaetura*  Tha  noda 
aoftwara  haa  baan  co^lataly  radaaignad  ao  that  tha  databaaa  can  ba  partitioned  in  a  aingla  noda»  to 
enable  anltipla  tranaactiona  to  run  in  parallal,  or  one  tranaaction  to  run  againat  different  parta  of  tha 
databaaa  in  parallal.  Tha  hardwera  daaign  utiliaaa  an  array  of  Innaa  Tranaputara  which  will  dallwar  a 
noAlnal  parfomanca  of  120  mlpa  par  noda. 

Thia  paper  daaeribaa  tha  overall  daaign  of  tha  ayataa  and  tha  banafita  available  from  adopting  auch  a 
eolation  to  tha  daal^  of  eilitary  raaltiea  ayataM*  It  alao  diacuaaaa  tha  daaign  iaat>aa  which  tha 
Tranaputar  architaetura  raiaea,  ^a  databaaa  eanagaaant  protocol  daaign  and  tha  approach  to  aalntaining 
databaaa  Integrity  in  tha  face  of  concurrent  parallal  tranaactiona* 

nffMoooCTrow 

Background 

Databaaa  eanagwaant  ayataiM  (OBNB)  firat  aada  their  appearance  In  eoaiareial  data  procaaaing  in  tha  early 
1970a,  with  producta  auch  aa  IMS,  AOIUUUI  and,  by  1978,  XDN8*  Thaaa  producta  propoaad  a  nutter  of 
dlffaxent  ondarlylng  data  aodala,  INB  being  baaed  on  a  aUipla  hierarchy,  whllat  IDMS  offered  a  aet  baaed 
network. 

All  of  thaaa  early  databaaa  ■■naijaaant  ayataaa  had  ona  vary  aignifieant  eharaetariatie,  which  cauaad 
thalr  databaaaa  to  be  vary  difficult  to  Maintain  and  evolve  over  tlM*  Thla  waa  that  their  Bodalling 
approa^  required  that  tha  aecaaa  patha  ba  hard  coded  into  tha  atructura  of  tha  data. 

By  tha  lata  1970a  a  new  data  Modal  had  aMargad,  tha  relational  aodal  [1].  Thia  Modal  raprsaantad  a 
radical  departure,  in  that  it  explicitly  aought  to  avoid  tha  encoding  of  accaaa  patha  within  tha  data 
atructura.  It  praaented  a  vary  aiiqtla  data  atructura,  2  dlManalonal  tables,  and  the  daaign  of  tha  data 
tablaa  for  a  given  applleatiMi  waa  baaed  on  tha  aaaantial  charactariatiea  of  tha  data  ItaMa  without 
rafaranea  to  tha  accaaa  raquiruManta «  It  waa  thia  Modal  whidt  Made  diatribution  and  parallallBM  a 
poaaiblllty. 

Although  by  tha  1980a  databaaa  producta  had  eo^lataly  invaded  tha  coaaarcial  coopting  world,  they  had 
Mada  very  little  ii^ct  on  real-tiMe  Military  coaputing.  The  raaaona  for  this  are  two-foldr  partly  tha 
way  in  abidi  Military  ooMputing  technology  davalopad,  and  partly  tha  diffarancaa  in  ayataM 
charactariatiea  between  tha  ijiaiarcial  and  tha  Military  aactor. 


nt  Of  Mllitar 


uting  Tadtoolo 


In  tha  1960a  and  1970a  eoMareial  ooivutara  ware  phyaically  rather  delicate,  and  thia  lad  to  tha  growth 
of  a  nu^r  of  apacialiat  organiaationa  who  built  rugged  coaputara  for  Military  applicationa.  Aa  thaaa 
Maehinas  ware  purpoaa  built,  they  ware  not  cowpatibla  with  tha  existing  oouMarical  ooeputars,  and  tha 
Manufacturara  could  not  achieve  the  eawa  eeonoMiea  of  acele*  Theee  Madtinea,  tharafove,  tended  to  ba 
vary  auch  Mora  axpanaiva  par  unit  of  co^uting  power  than  tha  equivalent  ooMMsrcial  Machine.  The  result 
of  thia  haa  baan  that,  in  aoftwara  anginaaring  taraa.  Military  coveting  h<.a  lagged  a  decade  behind  tha 
eoMMarcial  aactor. 


Thia  aituation  ia  now  rapidly  changing.  VLSI  (Vary  Large  Scale  integration)  technology  haa  brought 
inharant  ruggadnaaa  to  coMMareial  integrated  circuits*  This  technology  can  now  ba  utilised  for  military 
applications,  bringing  with  than  tha  coMwarcial  aeonoMiaa  of  acala.  Military  computing  ia  jumping  2 
ganarationa  of  hardware  and  thia  allowa  ua  to  adopt  coamarelal  aoftwara  engineering  approachea  Including 
Databaaa  Te^nology. 


tarn  Charactariaitica 


CCHMareial  data  procaaaing  ayatana  aaak  perfection  in  tha  realm  of  data  integrity.  If  an  error  occurs  in 
the  data,  tha  ayatam  ia  stepped  and  a  recovery  ia  run*  Moat  ooMaarcial  databaaa  producta  tharafora 
provide  a  recovery  aadianisM  which  loeke  out  a  large  part  (maybe  all)  of  the  databaee  whilst  a  leisurely 
recovery  ia  carried  out.  Cnemircial  producta  alao  tend  to  ba  tranaaction,  rather  than  raal-tima 
oriented. 
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To  vply  thoM  kind  of  prodncto  to  *  roAl'-tiao  AllltAry  applieotloa  «»oald  bo  totally  iaoppr^rtot*  • 
■oal^tiao  oyotoao  sook  hi^h  porfomoaeo  and  availability  aa  woll  aa  raliability*  Thora  aro  ao  coHMreial 
databaao  producta  that  can  ottox  tha  kind  of  parfnrnanra  oaadad  to  aupport  radar  traokiny  or  on-board 
avioaioa • 

Baal-Tina  Databaao  Wtniwant 

la  1980  Softwara  flcianoaB*  ondar  apoaaorahip  by  tba  Ok  Hiniotry  of  DafaneOf  ba^aa  iavaatiyation  into  tha 
problaaa  of  raal-tina  databaao  nana^anaat*  Oaring  a  pariod  of  about  2  yaara  an  initial  varaion  of  a 
ayataai  eallad  kODdM  (kdvanead  Oiatributad  Databaao  Nanagar}  ana  inplanaatad  (2,  4«  S,  6  c  7).  Zt  ia 
not  tha  porpoaa  of  thia  papar  to  praaant  tha  uork  carrlad  oat  on  tha  kODJUl  dovalopnant.  Bowavar,  aa  it 
waa  tha  AOOdN  uork  which  fomad  tha  baaia  for  tba  latar  ifork  which  thia  papar  will  diacuaa»  it  ia 
appr^riata  to  highli^t  tha  aaaantlal  davalopaanta  «dkieh  com  out  of  hDOM. 

APPdM  fundanantala 

ADDMl  waa  concaivad  ri^t  froai  tha  vary  baginning  aa  a  diatribotad  databaao  ayataai.  A  diatributad 
ayatoBr  proparly  if^lanontad#  bringa  two  eonpalling  banafita. 

Parallal  procaaalng 

fUgh  availability 

Tha  original  varaion  of  AOOAM  waa  inplanantad  on  18  bit  nini-conputara  utillaing  a  atandard  Von-Naunann 
architactura .  Thaaa  conpatara  wara  connactad  togathar  oaing  a  boa  architactarad  local  araa  natwork.  k 
local  araa  natwork  (LAM)  ar^itaetura  offara  a  troa  btoadeaat  facility*  idildi  ia  invaloabla  ia  kaaping 
natwork  traffic  to  a  niniJna  whan  anploylng  a  diatributad  databaao. 

ADDAM  offarad  a  fully  diatribotad  and  raplicatad  ralatlenal  databaao.  Any  nonbar  of  eopiaa  of  data  wara 
hold  around  tha  natwork  and  aa<di  noda  could  aeeaao  all  data.  At  tha  application  prograaning  laval, 
raplicatlon  and  diatrlbutlon  wara  not  viaibla.  AOOAN  providad  raliabla  and  aynehroniaad  propagation  of 
updataa  to  all  nodaa  that  hold  a  copy  of  a  data  itan  affactad  by  a  transaction. 

It  was  oMcludad  aarly  on  In  tha  pro)act  that  tha  ralational’  nodal  was  tha  only  sound  basis  for  a 
distributed  database.  Tha  oldar  typos  of  database  systsn  tended  to  be  heavily  pointer  based  in  their 
^yalcal  structure.  In  situations  «(hara  there  was  a  high  voIism  of  database  t^tdatas*  tha  networks  costs 
to  sMlntaln  large  pointer  chains  would  be  ao  high*  that  a  raal-tiaa  response  would  be  iapossible. 
Ralational  tables  are  physically  indepandant.  their  only  intar-ralationship  is  that  isposad  by  the 
application. 

Multi-user  concurrency  protection  was  inplanantad  using  an  i^iaistlc*  no  loek-on-raad*  protocol. 
Conventionally  database  systaas  protect  against  two  users  concurrently  sttesipting  to  update  the  saaa 
record  by  enforcing  a  lock-on-raad  algoriths*  witii  deadlock  detection  for  ualtl-lock  transactions.  In  a 
distributed  database  this  causes  a  large  nuabar  of  uassagas  to  flow  on  the  network.  Ibis  approach  also 
givaa  riea  to  tha  poasibility  that  a  longer  running  traneaotion  can  lock  out  a  ehortar  higher  priority 
one*  bacauea  tha  pariod  between  look  and  ocMit  ia  under  appliceticn  control.  AOOAN  only  locked  during 
the  execution  of  the  cosaiit  phaee.  We  tera  thie  an  optiaistic  protocol  becauea  it  aeeuaea  that 
concurrent  update  claahae  are  rare  occurancaa.  Whan  a  claeh  occure  tha  coet  of  rolling  back  tha 
transaction  that  can't  comit  ia  relatively  heavy. 

Only  ana  laval  of  porallaliea*  that  batwaan  tha  nodes  on  the  network*  was  offerad  by  A0l>AM.  This  allowsd 
s  throu^^^t  of  up  to  SO  trsnsactiMS  per  eecood  for  s  S  node  eyetea*  wbi^  wee  good  achieveaent  for 
its  tiae  snd  tha  technology  used. 

Tag  DIOMPW  8Y8T1 


Tha  DIONIDES  systaa  is  derived  froa  ADDAN.  Wbarass  AODAM  was  s  rasssrch  project*  DIONEDBg  is  s 
coMsrcial  product  which  has  taken  tha  original  APOAM  ideas  snd  dsvalopsd  thsa  vary  mndh  further.  Tha 
0I0NBDB8  hardware  architactura  previdaa  three  lavala  of  parallal  procaasingi- 

.  Tha  boat  and  DENE  functions  run  on  phyaically  saparata  processors. 

Tha  database  is  distributed  over  snltipla  nodes  on  s  natwork*  iMticb  allows  dstsbsae  functions  on 
diffsrent  nodss  to  run  in  parallel. 

The  OEMS  software  within  a  node  is  arranged  over  an  array  of  Traneputare*  idileh  allows  DBMS 
functions  running  on  ssch  Transputer  to  execute  ia  parallel. 

Tha  aoftwsra  design  also  providss  ooneurrancy  within  s  Trsnsputsr  by  sxplolting  ths  fact  that*  whilst 
data  is  being  traaaf erred  over  tha  syn^irooous  TTaaspotar  links*  ths  Trsaaputar  processor  can  carry  out 
ethsr  work. 

Ths  iacorporstion  of  psrallslisa  sad  distribution  within  ths  DBNE  sr^itseturs  involvss  s  cost*  oHisly 
ths  Introduction  of  ocwvisx  softwara  protocols  to  schievs  distrlbutsd  data  i^dsts  propagation* 
distributed  eoneurrancy  control*  sad  rssillsncs  and  racovary  fren  noda  failuraa.  Oonvantional  systans 
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attMpt  to  aolva  th«M  problaM  with  th«  om  of  «Mtor/aI«vo  and  handahalta  protoeola.  Ihaaa  proteooLo 
mrm  cemtly  in  mmaamgm  paaaiag  and  difficult  to  Inplaaant  and  taat*  DIOtODlt  ai^Ioita  a  rallabla  Local 
Aran  Mntwork  tyataaif  and  it  )iaa  alao  further  daeolopod  thn  optiniatie  proteeol  idea  by  introducing  a 
buffering  approeeb  uhiob  allowa  for  reliable  update  propagation  without  handahaklng.  An  efficient 
two-phaae  connit  protocol  baa  alao  bean  introdueed  to  auppert  aolti-updata  tranaaotiona* 

HABDWAW  MOLTI-Um.  >AKATJ.«r.Tt 


■oat  and  fWf  Separation 

DlOtODIS  puta  the  application  and  CNM  funbtiona  on  phyaieally  aeparate  proeaaaora  (aee  figure  1).  thia 
aeparatiott  prewidaa  aany  advantagea. 


Figure  1  •  Boat  and  DIMS  Beparation 

bhilat  the  DBMS  ia  proceaaing  an  application  <iuery#  the  heat  applioatione  prooeaaor  ia  free  to  carry  out 
other  aj^licationa  taeha.  in  a  general  tina«aharing  operating  eyaten  anwirotHaentf  this  neans  that  whan 
one  uaer  proceaa  haa  iaaued  a  databaee  requeat  to  DIomDBS*  it  ia  daachedoled  to  an  awaiting  Input/Output 
(1/0)  etate  ao  that  the  boat  CPO  can  then  be  awitched  to  proceaaing  another  uaer  application* 

The  aeperation  of  boat  appiicatlon  and  0BN8  functima  alao  neana  that  a  faatar  databeae  acceaa  reaponae 
can  be  a^ieved*  Thia  ia  becauae  the  D1QNBDB8  hardware  and  aoftwara  architecture  haa  been  deaigned  and 
optinieed  to  proceaa  databeae  acceaaee  In  real-tine*  The  DICMBDU  ayatan  containa  no  unneeeaaary 
operating  ayatan  acheduling/  I/O  driwera  or  nulti-uaer  anvlrowant* 

lha  iwe  to  Boat  interfaca  ia  deaigned  to  proeide  optinun  reeponae#  aa  ahown  In  figura  2. 


HOST  nwg 

HOST  SENDS  COWAND  - DHMS  BEGINS  EXICDTIOW 

IMNIDXATBLY 


HOST  INSTROCTS  0BK8  10  DEPOSIT  REPLY  1ST  TDPLB  RBTDfSfED,  OR 

IN  THE  BOTYER  PNOYIDED  ^ -  NOHl  IF  THEY  HAVE  BEEN 

ACCUNUUITBD* 

DM  COWnifDlS  EXECUTION 


ROST  INSTROCTS  DSNS  TO  DEPOSIT 
REPLY  IN  THE  BCPFER  PROVIDED 


DBMS  RITORlfS  YNOSB  YT7PLBS 
WHICH  IT  BAS  AOCDMDLATBD 
IN  mE  TIMB  IKE  HOST  TOOE 
TO  PROCESS  TEE  18T  BUFFER 
BTC. 


Figura  2  •  Hoet  to  DM  Tranaaetion  Protocol 

Nhen  a  hoet  prooeea  regweata  tuplea«  the  DM  buffM  eecheniaee  enaure  that  any  awailabla  tuplaa  will  be 
returned  ianedietely.  The  DM  done  not  welt  until  a  full  buffer  of  tuplea  ia  aeallabU  before  peeeing 
reeulte  baeic  to  the  hoet*  The  firat  result  buffer  ueuelly  contains  e  alngle  tuple  eo  that  tha 
applioetien  obtaina  e  result  in  the  aherteet  poeeibte  tiae*  Meegueat  buffers  contain  mltiple  tuplea  r 
aecwulated  by  the  OBMB  subsequent  to  the  prewioue  fetch*  to  the  liadt  of  the  ai^lied  buffer  slae* 
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P>rall#l  >roo«««in 


Ditgibat#d  I 


A  OKMnat  systM  eomai9t»  ot  •  mmbmr  of  oo-oporotioy  DM1  nod**/  vhieh  ao— unlcof  vlth  othor  ▼!« 
m  Local  Area  Watirark  (XJUi)#  aaa  figora  3*  fha  diatributloa  of  tha  databaaa  ovar  aaltlpla  nodaa  allowa 
appllcatloaa  on  dlffaraat  nodaa  to  aeeaaa  tha  databaaa  la  parallal. 


Pleura  3  -  Dlatribtttad«  A^iicatad  and  Partitionad  Databaaa 


Tha  databaaa  aay  ba  fully  raplleatad  in  all  DBMS  nodaa»  or  parta  of  tha  databaaa  nay  ba  raplicatad  on 
apaclfle  nodaa  only  (aaa  figure  3).  Ala  allots  tha  parta  of  tha  databaaa  which  ara  alwaya  accaaaad  by 
tha  applieationa  on  a  particular  hoat,  to  ba  raplleatad  locally  to  anaura  optinal  parfomanca. 


Within  tha  DBMS,  tha  unit  for  diatrlbution  and  raplicatlon  la  tha  partition*  Bach  relation  nay  ba  atorad 
in  ona  or  nora  partltlona*  Itaplaa  of  tha  ralatlon  ara  allocated  to  a  particular  partition  according  to 
tha  valua  of  an  attribute  (or  aat  of  attributaa)  known  aa  tha  partition  kav*  A  ralatlon  and  tha 
partltiona  In  which  it  la  atorad*  ara  illuatratad  In  figure  4*  Thia  figure  also  illuatrataa  aaqnanta 
which  ara  groupa  of  attribotaa  that  ara  nonwilly  updatad  togathar*  Aa  la  daaerlbad  later*  they  ara  tha 
unit  of  ooncur rant •update  eentrel* 


Pigura  4  >  DlonDM  Data  Btructuraa 


The  0MB  will  anaura  that  an  tvdata  to  a  raplioatad  partition  ia  conaiatantly  ^pliad  to  all  eopiaa  in 
tha  ayatan*  Tha  databaaa  partltiona  fora  aalf^ontainad  data  atroeturaa*  eontaiaing  no  aooaaa  path 
(pointnr)  infocaation*  and  ao  aa  i^pdata  to  a  ti^la  within  a  partition  only  affaets  that  partition. 

lha  databaaa  nay  ba  fnrthar  partitionad  or  raplieatod  within  a  aingla  OMi  noda  to  prowlda  parallal 
proeaaaiag  at  tha  node  lawal*  aa  diacuaaad  balow. 
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troo— iag  Within  k  Mod* 

B«eh  DtONSOM  nod*  eentninn  an  array  of  XMNOf  Tranaputara-  nia  Tranapntar  ia  a  slngla  chip 
■ioro-ooapatar  containing  a  vary  faat  procaaaor  (10  nipa)#  aanory  and  four  coMunieati<»  linka  vhieh 
provida  point-to'point  aynchroiMMia  oanaunication  to  othar  Tranaputara* 

Tba  Tranapotar  can  ba  oaad  in  nataorka  (oonnactad  via  th*  point-to-point  linka)  to  build  up  high 
parfomanea  ooncorrant  ayataoM  of  arbitrary  aiaa  and  topology.  Point-to-point  oo«Bunioati<Ni  ia  uaad 
inataad  of  coovantioaal  nulti -procaaaor  bua  ar^U.tacturaa  aa  it  avoida  coaounication  bottlanacka 
ragardlaaa  of  tha  nuabar  of  Itanaputara  ia  tha  ayataa. 

Soccaaafttl  aj^loitatioa  of  tba  Traaaputar  ar^iitaetura  raguiraa  tba  braaking  down  of  tba  problaa  into  a 
aat  of  parallal  prooaacing  taaka.  Por  anaapla*  a  aaareh  of  a  ralation  can  ba  dacoapoaad  into  a  aat  of 
parallax  partitiM  aaarebaa.  fba  taaka  «nat  than  ba  aappad  onto  a  topology  which  providaa  th*  optiniun 
cooputa-to  eo—Mnication  ratio. 

Iba  OIOWIDBS  Tranaputar  ardiitactura  ia  ahown  in  figura  5.  iba  data  in  aach  OIOMIDIS  node  ia  divided 
into  aavaral  diffarant  partition  grot^  aa^  of  which  contain*  a  cluatar  of  databaaa  partitiona. 
Partition*  nay  ba  raplioatad  in  a  aingla  databaaa  aachina  in  diffarant  partition  group*  to  raduea  accaaa 
contention*  la^  partition  group  in  napped  onto  one  Trenaputer,  which  enable*  any  given  aearch  or 
concurrent  group  of  eeardiea  to  be  perforaed  in  parallel. 


TO  APPLJCATION  HOST  PROCESSORS 


TO  LOCAL  AREA  NETWORK  (LAN) 


Figure  5  -  DIONBDSS  Tranaputar  krehitecture 


J^plieation  read  requeata  ar*  broken  down  into  e  aet  of  work-packagaar  aa^  of  which  relate*  to  a  eiag>le 
funotlm  (e.g.  an  index  eaer^  of  e  partition).  Iheae  work-peckagee  are  routed  to  the  appropriate 
Tranaputar  which  ia  aaintaining  a  copy  of  the  ^levant  partitiona. 

J^lication  update  requeata  are  broken  down  Into  e  aet  of  work-peckgea  f  each  of  whi^  «4»dataa  e  aingla 
partition.  Thea#  work-peckagw*  are  routed  to  the  appropriate  Tranaputar  for  dietribntlm  ovar  tha  local 
Area  Ratowrk. 

In  ordar  to  aehiav*  raal-tlna  (aub  10  nllll-aaoend)  raaponaaa  to  application  raquaate,  all  data  ie 
naintainad  within  nain  nanory.  At  raguXar  intarvala  c^iae  of  t))*  data  era  baekad  up  to  diac.  If  a 
partition  ia  raplieatad  within  a  node,  than  only  on*  copy  i*  backed  up.  nia  backip  o^y  anablaa  tlia 
ayataa  to  raeovar  tha  databaaa  after  failuraa. 


I 


. . i 

^ _ -  _ 


ii-.r 
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fhm  softiMr*  proe«SMS  oo  TrAMput«r  «r*  6Mi9n*d  to  Mrrlco  ■oltlplo  ooor  roqoMts  oonoorrontly 

(MO  flgor*  6).  Am  softwAro  prooMMA  AutOMtlCAlly  AchAdulA  th— olv—  to  th«  roquost  Boat 

urqAtttly  to^iiroA  pmoAMing#  lUMly  that  «hArA  th*  hoot  !•  OMUtiag  fartbor  tuploa  or  haa  an  updata 
oatatandiaq. 


host  DBMS 


Plqora  6  •  Multl^thraadad  ParallaL  Prooaaaing 
Dacouplar  and  Cantral  Sarricinq  Procaaaaa 

A  prooaaa  on  ona  Tranaputar  can  only  land  a  naaaaqa  to  a  proeaaa  on  anothar  Tranaputar  if  tha  raeaiaar  It 
waitlnq*  bacauaa  Tranaputara  coaaninicata  oaar  poiat~to»point  aynchroooua  llnka*  In  ordar  to  achiaaa  a 
larqa  daqraa  of  parallal  proeaaainq#  tha  procaaaaa  on  aach  Tranaputar  haaa  to  ba  daoouplad  froa  aaeh 
othar* 


tha  DIOKIOBS  daaiqn  dacouplaa  tha  tranafar  of  data  bataaan  Tranaputara  froa  tha  Mlnatraaa  procaaaing  by 
intarpoalnq  anothar  proeaaa*  aaa  figura  7. 


Pigura  7  ^  Oacouplad  Procaaaing  and  COMunicatlona 
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■WMOMt  faOTOOOLl 


»»li«biXity  frotocoXs 

Th*  LAH  vnaur**  that  Msaagaa  «r«  rallably  daliy«r*4  to  doatinatjoii  nodoa.  ha  tha  natwork  la 
aayndirocMMM,  it  la  poaalbla  that  aaiaagaa  ooold  ba  dallaarad  to  a  aoda  faatar  than  that  noda  eaa  proeaaa 
thaa*  lac^  noda  la  tharafora  raqoirad  to  pcoaida  a  pool  of  buffara  larga  anoagh  to  auiw— iiilala  tha 
graataat  paaka  la  aaaaaga  daliaary  that  it  la  ai^aetad  to  aapaalaoea.  fhla  la  tha  raaponaibtlity  of  tha 
mis  daaignara  for  a  particular  applieatloa>  If  tha  noda  doaa  ai^arlanea  buffar  asdiauatlon  than  It  la 
ahttt*-do«n  and  ra*atartad  aa  though  It  had  auffarad  a  hardaara  failura. 

Thla  cptinlatlo  buffaring  protocol  raaovaa  tha  naad  for  handahaklng  but  It  doaa  a  hi^iar  ovartiaad 
ahottld  buffar  ovarflou  occur*  In  addition  to  raduclng  aatuork  load*  optiaiatle  boffarl.ig  raduoaa 
traaaaotlon  lataney  by  raaaaing  tha  naad  to  ualt  f^  raaponaaa* 

Sacoyary  and  Waplicatieo 

k  DIONDIS  ayataa  la  looaaly  oouplad.  Iba  failura  of  any  alngla  databaaa  Bachina  oonnactad  to  tha 
natwork  affaeta  only  tha  locally  attached  applicatioa  proeaaaaa.  baoonnactioo  and  racovary  of  fallad  or 
additional  nodaa  la  achiawad  without  braaka  in  ayatOB  aarvlca*  thla  allowa  raal-tlaa  appllcationa  to  ba 
raloeatad  and  co«ordlnatad  acroaa  any  numbar  of  nodaa  within  a  dlatrlbutad  proeaaalng  natwork. 
Appllcationa  any  ba  co*ordlnatad  ala  tha  databaaa. 

■ach  0SH8  noda  laplananta  Ita  DBMS  functlona  aayn<dironouaIy  froa  othar  nodaa.  No  two  nodaa  ara  dadicatad 
In  a  dlalogua  whan  parfonalng  any  databaaa  oparatlon.  All  DBMS  nodaa  ara  kapt  In^atap  by  tha  update 
ayehronlaatlon  and  naturally  "mirror”  one  another,  failura  of  a  noda  doaa  not  require  any  ramaining  noda 
to  taka  apaciflc  recovery  actioae. 

COWCimRlWCY  COWTWOL 


OIOHIDCS  providae  ooncurrancy  control  at  tha  ae^ent  laval*  aaa  figura  4.  Control  ovar  auoh  amall  unite 
maana  that  concurrent  updataa  ara  vary  unlikely  to  claah.  A  protocol  la  uaad  which  la  optimlaad  for  tha 
oaaa  whan  no  concurrency  claah  oecura. 

Tha  08NS  doaa  not  lock  data  in  tha  conventional  aanaa.  Data  may  ba  raad  at  any  tlna.  Dpdataa  nay  ba 
attamptad  at  any  tlaa  and  will  only  fall  If  tha  data  being  updated  haa  bean  altered  by  another 
application,  ainea  tha  updating  application  flrat  raad  It.  In  aaaanca  tha  approach  la  to  lock -on -write 
rather  than  lock-on-raad.  that  la,  a  write  to  a  tuple  locka  out  any  prior  raadara  trem  updating.  Nhan 
an  update  traneectlon  fella  due  to  prior  update,  then  tha  whole  tranaactlon  la  rolled  hack  and  reported 
to  tha  Initiating  application  which  euat  than  re-atart  It. 

thla  approach  haa  three  aajor  advantagaa: 

•  tha  lack  of  raad  locka  raducaa  rn— unlcatlona  traffic  and  tranaactlon  latency. 

.  Deadlock  detection  algorlthaw  ara  not  required  (aa  they  ara  with  lock -on -raad ) . 

.  Slow  running  tranaactlona  cannot  lock  out  urgent  onaa.  thla  la  vary  liqx>rtant  In  raal-tlma 
and  unitary  appllcationa. 

TWO  PHASS  COPWIT  PROTOCOL 

In  any  aarloua  application  tha  databaaa  uanagauant  ayatau  atuat  provide  a  facility  for  appllcationa  to 
Isaua  update  tranaactlona  which  change  more  then  ^a  phjraleal  record  In  tha  databaaa.  thla  la  taruad  a 
"Multi -Update  Cnwlt-Unlt".  Nhilat  a  uultl-vg>data  cOMlt-unit  la  being  axacutad,  tha  databaaa  la 
Inconalatant.  It  la  conalatant  before  tha  coault-unlt  atarta  and  on  eouplation  of  tha  ecauU-t-unit .  The 
mis  Buat  ba  able  to  guarantee  that  «  couult-unlt  once  atartad,  either  ooa^lataa  norually  or  la  rolled 
back.  In  a  dlatrlbutad  databaaa,  tha  protocol  required  to  a^iava  thla  la  called  a  two-phaaa  cosit 
protocol . 

Tha  DtGMB>B8  two  phaaa  coaudt  protocol  haa  tha  following  atagaas 

a)  Tha  Initiating  node  broadcaata  the  fraguanta  of  tha  tranaacti<m.  A  fra^wnt  la  an  update  to  a 
aaguant  -  tha  unit  of  ooncurrancy  control. 

b)  All  nodaa  receive  tha  fraguanta,  and  thoaa  holding  a  copy  of  tha  data  to  ba  updated  atora  thau. 

c)  Whan  all  tha  fragpaata  of  tha  tranaactlon  have  bean  broadoaat  tha  Initiator  broadcaata  a 
*prapara-to  r.ijuuAt*  uaaaaga. 

d)  On  receipt  of  tha  prapara-to-coMit,  each  noda  which  haa  atorad  tha  fra^Hmta  chacka  to  aaa 
whether  they  can  ba  applied.  If  a  concurrency  claah  haa  oocurad,  a  'rollback*  uaaaaga  la 
broadcaat. 

a)  If  it  ia  poaalbla  to  apply  tha  tvdata  a  *raa^-to  couuit*  atata  ia  eat  to  indicate  a  transaction 

la  In  prograaa  on  this  data. 

f)  A  'raady-to-oouuit*  uaaaaga  ia  broadcaat  indicating  Which  parte  of  tha  tranaactlon  thla  node  can 

nnault. 
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9)  Wmh  •offieiaat  *r#«dy-tri  crwit*  — h*v*  b**a  r*Pttiv*df  th*  transAction  !•  ooaBlttad. 

h)  If  •  rollback  aaaaaga  la  raeaicad#  aag  'raadytoocMOlt'  flags  sat  ara  elaarad  and  tha 

transaction  fra^ssnts  am  discarded^  so  abaadoniag  tha  transaction* 

1)  Saob  nods  will  salt  for  sofflclant  *rosd*to-oo^lt *  sossagos  for  a  pradstamlnad  tlos*  If  a 

asssags  Is  not  rooalaod  for  mmdk  partition  participating  In  tha  transaction  (l>s.  a  nods  has 
failad  sad  no  oepg  of  a  aslant  anlstsl  ehoa  tha  tranaaotloa  is  rollsd  back* 


Off-Llns  Qnsry  Optlalsatlon 

Applications  aecass  tha  databasa  using  sabsddsd  gosry  laaguaga  stat—snts*  Bsfora  thssa  oaa  bs  run,  tha 
application  oust  ba  proeassad  bg  cha  OIQMKttd  pra>oenpliar,  which  eonwarts  tha  anhaddad  query  language 
into  calls  to  tha  DIOKIDIS  run^tlns  library  proeaduras* 

The  OXOMmS  praoeavllar  oonsldars  possible  acoass  path  stratagias  and  gansratss  the  nest  efficient  query 
plan,  ensuring  that  the  nlniauB  anount  of  procesaing  needs  to  ba  dene  at  runtlne  (sea  figure  8)* 


PROCESSMQ  STAHOAf^O  SOL  QU£Rt£8 

vt 

PAECOMPIIEO  OLiERlES 


STANDARD 

SOL 

QUERY 


Pans 


Optkntia 


Subatihila 

Paramsiarf 


Osla 

Diciionafy 


Dau 

Dictionary 


Exscutt 


Figure  8  >  DIOIODn  Praconpilad  Quarles 
The  lutln  functions  of  tha  praconpllar  arat 
Cesaand  aerification. 

Kapanslon  of  aievs  into  base  relations. 

.  Qoory  cptlnlution. 

Daconpostlon  of  the  query  Into  its  basic  alnnants.  Including  operators  to  enforce  refarantial 
Integrity. 

Calculation  of  access  path  stratagias  for  each  query  alaaont. 

Generation  of  candidate  query  plans  and  salactlon  of  tha  noat  efficient. 

Generation  of  calls  to  library  prooaduras  in  order  to  sand  oosMnds  to  the  OBMS  and  to  fetch 
the  results  of  those  rcemsnds* 
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lynt  Drtva  Qory  8Tvio» 

ItMl-tiJM  aystatts  ara  diaraetariaad  by  tha  fact  that  thay  ata  avant  drivaa.  In  a  DIONSDBS  ayataa. 
raal'^laa  avanta  are  ra«>rdad  at  aa^  DIQMtOKS  node  and  are  antoaatieally  propagated  to  all  applicationa 
requiring  notification  of  tha  event*  aaa  figure  9*  Iba  avaata  are  ragiatarad  by  updating  tuplaa  in  one 
or  morm  databaaa  ralationa.  At  a  particular  j^plicationa  node*  knowledge  of  only  a  aubaat  of  evanta  nay 
be  required  for  tha  node  to  carry  out  ita  function.  ghia  aubaat  nay  be  defined  by  apacifying  tha 
aignif leant  level  of  change  within  tha  ralationa  uaad  to  atora  tha  evanta. 


Figure  9  -  0Z0MBDE8  Raal-Tina  Bvant  Notification 

An  application  can  enrol  to  receive  notification  of  aignif leant  evanta  by  uaing  tha  NOHttOR  coenand  (ef. 
SQL  'CURSOR*)  to  read  data  tram  tha  databaaar  aaa  figure  10»  On  receipt  ef  thia  onawind  tha  local 
OIOPCBJCS  databaaa  ■aehina  la  configured  to  rawaebar  which  databaaa  changea  are  aignifleant  for  the 
particular  application,  tvery  tlaa  a  "nomitohKD*  event  occura*  the  databaaa  automatically  aatiafiaa  the 
outatanding  read  and  raturna  the  data  to  the  application.  Thia  data  nay  ineXuda  not  only  the 
event^related  data*  but  all  the  appropriate  contextual  data  relevant  to  the  event. 

OSCIARS  Track  NONITOR 

SSLICT  (Trackid*  range*  bearing) 

FHOH  traok^'table 
NBXRB  ranga  <  1000 
AND  NOTIFT 

NIIBI  MUnS  UPOATn  BT  10  AND  INSBRnONS  AND  DCLBTIOmr 
START  Track! 

Ft  TCI  Track  INTO  iio«of>tra^*  ranga^f'^raek*  bearing-of  •.track! 
(lapeat  aa  required) 

STOP  Track! 

Figura  10  -  Ivent  Driven  Monitor 

Ivent  driven  query  aervioa  offera  four  aignif leant  banafltat 

.  All  aignificant  eventa  are  recorded  in  tha  databaaa. 

laeh  event  a«y  autoauitically  trigger  aavaral  raaponaa  modulaa  at  me  or  aora  nodes  in  tha 
network. 

An  application  procaaaor  only  receives  significant  data  from  tha  databaaa  *  and  ao  no  tlma  ia 
expanded  at  tha  application  procaaaor  in  close  ooi^lad  dialoguaa  with  tha  databaaa.  All  data 
received  ia  actlonabla. 

Any  nttflbar  of  nodas  can  respond  at  any  level  of  aignifieance. 

Although  several  respondara  at  different  nodes  may  action  aa  evwt*  each  event  la  tranamittad  around  tha 
network  only  once. 
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Ih*  •Maaplrn  «bov«  sbows  bow  •  MOIIITOR  !•  d«cl«r*<t  And  UAAd*  flic  nelAct  cfcACAMat  dAfinna  the  doMAln  of 
Internet,  ell  trecke  with  «  ren^e  of  lee#  then  1000*  Joitlelly  ell  trecke  within  the  doMin  ere 

returned  to  the  Applleetion*  Motif leetiM  ie  then  sent  of  eny  of  the  following  events  i 

•  k  ehenge  in  the  renge  of  e  treek  in  the  dwAin  of  interest  by  10  or  eore.  Mote  thet  if 
severel  cheoges  of  less  then  to  oeeur,  the  eppliestion  is  not  notified  until  the  overell 
Chengs  is  10  or  nore  siaoe  the  renge  of  thet  treck  wee  sent  to  the  eppliestion. 

Inserti<Mi  of  e  truck  into  the  doeein  of  interest,  either  by  insertion  of  e  new  truck  or  by  s 
truck  outside  the  doeuin  huving  its  rungs  upduted  so  thut  it  is  less  then  1000. 

•  Oeletion  of  u  truck  free  the  dosuJn  of  interest,  either  by  deletion  of  the  truck,  or  by  u 
truck  in  the  deeuin  huving  its  rungs  upduted  so  thut  it  is  1000  or  More. 

the  NOMltOR  Sturt  initiutes  the  retrievul  operution  end  sets  the  MOHITOk  position  to  be  effectively 
before  the  first  tuple  of  the  logieul  tuhle  returned  to  the  eppliestion.  Fetch  eewsunds  ere  used  to  copy 
one  tuple  et  s  tias  into  Application  vurisbles  for  processing.  Mhsn  the  MONITOR  is  no  l<Miger  required  it 
is  St<9pAd. 

8Y8TW  PtIUfOIMMUICB 

In  order  to  predict  the  likely  perforMsnee  of  biaHB>B8,  e  Modelling  prograsae  was  carried  out  as  a 
psrsllsl  activity  during  the  early  stages  of  tbs  DICMfDn  dsvelepasnt.  the  teua  used  an  unulytlc  aodel 
thut  sivloyed  u  puruauturisud  queuing  ulgoritiM  for  aodelllng  the  delays  sssocistud  with  Trsnsputar 
processor,  link  and  data  contention.  An  sabsddud  UlM  aodsl,  that  uaployed  a  protocol  specific  ulgoritha, 
was  used  to  eslcuLste  the  inter-node  coaaunicetioRs  delays.  All  input,  interaedlste  end  aodelllng  result 
data  was  stored  within  an  Oracle  databese.  Ihia  data  waa  than  intarrogutad  by  aeana  of  a  Query  Tool 
whi^  allowed  the  developaent  teaa  to  ”sooa  in*  on  ^e  i^ortant  parfomenee  problaae  (e.g.  the  Most 
heavily  loaded  Truneputer  or  the  aoet  delayed  treneectlon)  end  allowed  these  problaae  to  be  traced  beck 
to  the  eeusel  input  data. 

The  aodelllng  tools  ware  recently  used  to  predict  the  DI0NIDI8  configuration  that  wee  neceeeury  for  a 
ayataa  whi^  requirad  a  parforaance  of  450  t^pdatae  and  1500  reads  par  aacond.  The  proposed  design  was  a 
DIQHtDtM  ayataa  ocapriaiag  8  nodes,  with  each  nods  containing  11  T414  Insoa  Transputers,  the  database 
wee  to  be  fully  replieeted  in  aaaory  at  each  of  the  nodes,  and  the  nodes  were  to  cowunicuts  via  a  3 
Hblt/aec  liUl.  8oau  050  different  acceaaea,  ea^  at  a  diffarant  frequency,  were  identified,  to  s  dAteheee 
coaprieing  85  date  partitione. 

Tha  Apacifle  araaa  of  concern  were  in  the  UM  loeding  and  tha  aaount  of  paralleliSM  that  could  be 
echieved  using  ths  Transputsr  srchlteeture.  Ths  perfonuines  snalysis  esrrtsd  out  showed  that  the  IAN 
loeding  was  well  within  the  aeceptid>le  range,  but  one  Trsnsputer  within  one  of  the  nodes  was  predicted  to 
be  MS  loaded*  which  was  judged  unaocepteble.  this  discovery  led  to  en  iteration  of  the  design  which 
replacwd  the  T414  with  the  faster  T800  floating  point  Transputer,  end  divided  the  heavily  loaded 
TraMvttter  functions  over  two  Tranaputera.  this  rssuited  in  s  revised  MeaijMM  Transputer  loading  of  2U. 
the  evaluation  also  showed  thet  the  latency  for  updates  and  rsada  (sub  10  nilli-ssoonds)  were  wall  within 
the  reqoirssMnta  of  the  application* 

APPLICATlq—  OT  0I0WMDM8  TMCBMOLOCY 


OIOHBHM  was  daaignad  specifically  to  fill  the  gap  that  axlsted  in  the  provision  of  dstebsse  tschnology, 
for  real'*tiMS  eystsMS.  It  provides  s  high  psrformsnes  and  high  availability  relational  databaae 
aanaguMMit  aystaM. 

DIcraoM  providae  hoth  eoonoMic  and  te^inologioal  benafits  to  tha  aystsM  lapleMentor.  It  significantly 
raduoaa  tha  eoMplanity  and  coat  of  applications  progrsaMing  bseauss  it  tskss  responsibility  for  all  date 
nenagsaant  tasks.  Otoimn  also  takas  responsibility  for  data  distribution,  routing  and  replication 
nanagsaant.  Applications  can  thersfora  bs  dssigned  and  wrlttsn  as  though  thsy  were  ell  to  run  on  a 
single  o^trelieed  eenputer.  in  practice  the  applicetiens  can  nigrata  around  thu  systaa  and  the  ayaten 
can  grow  by  the  eddition  of  extra  nodas  without  any  ehangaa  to  application  prograaa.  otoMEDKs  has  been 
daai^ied  apecifically  as  a  diatributed  ralaticnal  database  nanifent  aysten.  It  brings  bsnsfits  such  as 
distributsd  two-phase  covit  and  concurrancy  control  which  ara  too  difficult  or  inpractical  to  ijq>laMent 
at  the  application  level. 

DIONDU  is  suitabls  for  systsns  which  Involve  hundreds  of  slMultansous  evsnts  to  which  a  tins  critical 
rasponae  nust  bs  nsds.  It  is  cspsbls  of  handling  large  voIums  of  updates  and  retrisvals,  for  databases 
thst  can  range  np  to  nnny  Megabytes  in  site. 
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DISCUSSION 


A.O.Ward.  UK 

We  can  identify  the  sending  of  data  as  a  limitation  in  the  performing  of  future  airborne  knowledge  based  systems.  Do 
you  think  that  your  DBMS  would  be  of  use  in  such  applications? 

Author’s  Reply 

In  principle  yes.  The  DBMS  provides  a  parallel  searching  capability  and  this  could  be  utilized  for  fast  searching.  There 
might  be  a  problem  with  partitioning  the  data  depending  on  the  application  and  the  nature  of  the  knowledge  based 
system.  The  DBMS  could  also  manage  the  data  updates,  integrity,  recovery,  etc.  and  its  distribution  on  the  system  bus. 


W.Mansel,  Ge 

How  have  you  realized  synchronization.s  between  data  transfer  and  the  data  base  updates? 

Author’s  Reply 

The  data  highway  synchronizes  all  database  updates,  including  those  between  network  modes  and  those  between  strips 
on  the  same  mode.  The  highway  provides  a  reliable  serialising  transport  layer. 
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SOMHART 

The  programming  and  implementing  of  embedded  real-time  computer  systems  is  one  of 
the  most  difficult  problems  of  data-process  technology.  The  parallel  and  non  deter¬ 
ministic  actions  within  the  systems  are  hard  to  describe  and  to  check.  Nearly  all 
languages  designed  for  real-time  applications,  as  e.  g.  real-time  FORTRAN,  Coral  66, 
RTL/2,  etc,,  are  incomplete  tools  to  solve  the  problem  of  concurrency  because  of  their 
inherently  sequential  nature.  The  programming  language  Ada  offers  constructs  for  the 
description  of  task  interactions  in  a  very  abstract  manner  without  relation  on  the 
architecture  of  the  target  machine. 

This  paper  describes  the  harmonization  of  a  message  driven  distributed  machine 
architecture  with  the  programming  language  Ada.  The  problem  of  concurrency  is  described 
in  general  and  a  communication  concept  for  task  interactions  is  proposed.  Analysis  of 
the  real-time  requirements  for  future  applications  leads  to  the  definition  of  a  set  of 
message  types,  where  deterministic  and  underterministic  task  interactions  can  be 
achieved.  Based  on  this  definition  a  distributed  machine  architecture  is  presented  that 
consists  a  network  of  computing  units  and  an  autonomous  communication  system,  designed 
to  reduce  all  administration  work  to  a  minimum.  A  special  "no-wait-send"  communication 
procedure  is  modeled  in  Ada  language.  Restrictions  and  augmentations  for  Ada  pro¬ 
gramming  language  are  worked  out  subsequently  and  demonstrated  by  examples.  This  paper 
shows  that  Ada  has  valuable  constructs  for  the  description  of  even  hard  real-time 
applications  by  defining  the  right  system  concept.  This  concept  is  based  on  a  message- 
driven  distributed  machine  architecture  and  an  autonomous  communication  procedure. 


GLOSSARY  OP  TERMS 

APSE  Ada  Programming  Support  Environment 

ASIC  Application-Specific  Integrated  Circuit 

C  Consumer  Task 

CPU  Central  Processor  Unit 

HOL  High-Order  Language 

KAPSE  Kernel  Ada  Programming  Support  Environment 

MB  Mail  Box 

MAPSE  Minimal  APSE 

P  Producer  Task 

PAMELA  Process  Abstraction  Method  for  Embedded  Large  Applications 

PDL  Program  Oeslgn/Documentation  Language 

RAH  Random  Access  Memory 

VLSI  Very  Large  Scale  Integrated  Circuit 


THE  PROBLEM  OP  CONCURRENCY 

Data  processing  under  real-time  conditions  more  and  more  becomes  the  essential  key 
in  avionic  and  defense  systems  as  well  as  in  the  automation  field.  Real-time  processing 
In  embedded  computer  systems  means  the  computing  of  sensor  data  under  the  conditions  of 
undetermined  events  and  fixed  time  limits  for  the  purpose  of  process  action  and  con¬ 
trol.  Beyond  their  future  applications,  as  e.  g.  "flight  control",  "autonomous  target 
identification",  "multisensor  fusion",  "aircraft  robotics",  etc.,  they  additionally 
request  the  concurrency  of  different  tasks  which  correspond  to  efsch  other. 

However,  the  methods  and  procedures  of  today’s  data  processing  do  not  really  meet 
the  application  requirements  given  and  well-understood.  This  can  be  seen  from  the  tre¬ 
mendous  costs  of  big  software  projects,  the  instability  of  time-'lmlted  systems,  the 
maintenance  problem  after  Implementation .  Big  efforts  have  been  made  to  overcome  some 
of  the  problems  addressing  singular  aspects,  such  as  high-order  languages  (HOLs),  soft¬ 
ware  development  tools  and  high  performance  CPUs.  Practice  has  shown  that  these  ap¬ 
proaches  help  only  partially  in  real-time  applications  and  that  they  create  other  prob¬ 
lems.  The  problem  of  concurrency  is  generally  not  supported  today.  Five  reasons  will  be 
outlined  to  support  this  statement: 

o  The  programming  method  is  not  problem-oriented  even  in  case  a  problem-oriented  pro¬ 
gramming  language  can  be  used.  The  development  costs  are  increasing  more  quickly  than 
the  complexity  of  the  problem.  The  real-time  problem  Is  considered  in  the  sequential 
way  of  programming.  However,  the  structured  analysis  of  the  application  problem  cre¬ 
ates  a  net  of  tasks  Interacting  by  message  transfers.  That  is  adequate  to  the  prob¬ 
lem.  If  conventional  programming  methods  are  used,  this  comprehensive  network  of 
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tasks  will  be  destroyeci  during  iopleaentation .  This  results  In  bad  planning  of  real- 
tine  behavior. 

o  A  lot  of  sophisticated  tools  for  programming  and  execution  have  been  invented,  such 
as  multiprocessor-multitask  runtime  systems,  task  priority  management  etc.,  to  pro¬ 
vide  implementation  help  to  the  programmers.  This  system  software  helps  to  synchro¬ 
nize  the  process  and  to  standardize  the  technical  approach.  However,  it  spoils  the 
software  and  hardware  transparency  and  so  the  testability.  Furthermore,  the  useless 
administration  efforts  consume  valuable  processing  time. 

o  In  moat  computer  systems  the  synchronization  of  tasks,  events  and  hardware  resources 
is  achieved  by  administration  in  a  centralized  version.  This  fact  does  not  make  em¬ 
bedded  systems  modular,  but  rather  very  sensitive  to  disturbances  and  faults.  Mes¬ 
sage-driven  concepts  /2/,  /6/,  /t1/  are  of  great  Interest  to  solve  this  problem  in 
future  computer  systems. 

o  The  high-order  languages  (HOLs)  help  to  establish  big  software  packages  at  the  cost 
of  execution  time,  storage  size  and  ccMDpilation.  In  real-time  applications  these 
parameters  have  a  tremendous  impact  on  the  overall  design  of  the  target  machine. 
Therefore,  a  consistent  development  environment  is  required  including  test  facilities 
and  real-time  simulation.  However,  sometimes  the  tools  become  so  complicated  and 
inflexible  that  no  reasonable  tradeoff  can  be  calculated. 

o  Concerning  the  hardware,  computer  buses  were  standardized  based  on  administration 
principles  that  permit  a  computer  to  be  configurated  according  to  a  specific  applica¬ 
tion  without  detailed  knowledge  of  the  circuits.  In  multiprocessor  systems  of  that 
kind  bus  arbitration  and  resource  allocation  have  to  be  solved  instantly  by  a  cen¬ 
tralized  administration.  In  many  cases  the  expansion  of  performance  is  therefore 
limited  and  makes  the  implementation  very  complex. 

In  the  future,  the  problem  of  concurrency  has  to  be  solved  by  another  approach 
bringing  into  harmony  all  the  different  requirements  for  standardization,  regularity 
and  flexibility  of  software  and  hardware  during  all  phases  of  implementation.  The  re¬ 
sulting  embedded  computer  systems  have  to  be  less  complex  and  must  be  easy  to  change. 
The  following  three  principles  should  be  applied  to  follow  new  ways  in  the  real-time 
data-processing  world: 

a)  Using  Ada  for  designing  and  programming  real-time  software  packages  in  a  standard¬ 
ized  manner  to  yield  all  known  benefits  -  High  Order  Language  (HOL). 

b)  Problem-oriented  software  structure  with  direct  software  on  hardware  allocation  in 
distributed  machines  -  Network  Frograsalng. 

o)  Substitution  of  administration  efforts  by  communication  resulting  in  a  message- 
driven  system  -  Autonomous  Cooaunication. 


A  CONCBPT  OF  RBAL-TINE  CX)NMUN1CATI0N 

Using  the  known  methods  and  procedures  of  structured  analysis  Is  the  way  of  star¬ 
ting  to  solve  the  problem  of  designing  real-time  embedded  computer  systems.  Real-time 
applications  are  to  be  described  as  networks  of  communication  tasks.  Application-spe¬ 
cific  network  topology,  computing  performance,  storage  size,  etc.  are  elements  of 
description.  Fig.  1  shows  the  general  structure  of  embedded  computer  systems  realized 
in  distributed  machine  architecture. 


The  general  structure  requires  the  necessary  resources  to  be  permanently  available 
to  each  task.  Tast  interactions  are  carried  out  by  message  transfers  in  unidirectional 
communication  units.  Various  theoretical  studies,  e.  g.  /1/»  /2/,  /3/t  describe  and 
prove  the  functionablllty  and  stability  of  this  embedded  computer  system  realized  In 
network  structure. 
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In  the  network  the  mesaagea  ahould  he  transaltted  in  a  flow^orlented  and  runtime- 
neutral  way  without  adolniatration  efforta  impeding  the  taak  runa.  The  communication 
adolnlatratlon  necesaary  in  the  older  embedded  computer  ayatema,  trtilch  la  a  burden  to 
the  ayatem,  la  now  replaced  by  an  autonomoua  communication  ayatem.  The  ayatem  haa  to 
carry  out  taak  interactlona  concurrently  with  the  taak  actiona.  Only  in  thla  way  can  an 
optloum  real-time  behavior  of  the  atructure  be  achieved. 

Communication  concepta  thoae  can  be  uaed  for  the  execution  of  taak  Interactlona  are 
deacrlbed  in  varloua  publlcationa«  e.  g.  /V,  /5/,  /6/,  /?/.  The  uaable  concepta 

o  remote-taak-aend 
o  remote-invocatlon-aend 
o  aynchronization-aend 
o  no-walt-send 

will  be  analyzed  with  reapect  to  operationability  In  the  chaptera  to  follow.  Theae  con¬ 
cepts  control  task  interactlona  with  different  transfer  procedures  and  software  and 
hardware  components.  Pig.  2  shows  principles  of  the  communication  concepta. 

The  communication  concepta  "remote-task-send*  and  "remote-lnvocatlon-send"  are  syn¬ 
chronous  communication  models.  They  transfer  messages  only  on  request  of  the  consumer 
or  producer  task.  In  the  "remote-taak-aend”  concept  taak  Interactlona  are  initiated  by 
a  GIVE  request  of  the  consumer  task  to  the  producer  task  and  in  the  "remote-invocation- 
send"  concept  by  a  TAKE  request  of  the  producer  taak  to  the  consumer  taak.  Theae  re¬ 
quests  force  the  synchronization  of  producer  task  and  consumer  task.  After  synchroniza¬ 
tion  was  successful,  the  tasks  exchange  the  message  of  the  task  Interaction.  In  dis¬ 
tributed  architectures  there  are  three  different  kinds  of  task  interactions  which  are 
shown  in  table  1.  Both  concepts  mentioned  above  support  only  task  Interactions  of  the 
kind:  single  producer  to  single  consumer  task.  All  further  task  Interactions  of  table  1 
will  not  be  supported.  However,  all  possibilities  of  realization  are  necessary  for 
efficient  distributed  machines. 


Remote -fask- send 


rtquf*  GIVE 
TAKC  meaaqt 
confirmation 


Remote  -  invocation  -  send 

rwmt  TAKE 
coftfirmehon  Q\€ 

mawago _ 

cenfirmotion 


Sychronization-send 

(tyghtCy  coupiatf  orchtttchirv^ 


P:: «  Producer  fash 
C  :  s  Corwacr  tosh 


No-wait-send 

( loosely  coi4>led  architecture) 


FIGURE  2:  PRINCIPLES  OF  COMMUNICATION  CONCEPTS 


The  communication  concepta  "synchronlzation-send"  and  "no-wait-send”  are  asynchrous 
communication  models.  Their  implementations  require  differen*'  hardware  and  software 
structures . 

The  "synchronlzatlon-send”  concept  Is  designed  for  tightly-coupled  structures.  It 
transfers  messages  via  multi-access  structures,  such  as  mall  boxes  or  shared  memories. 

The  ”no-walt-send"  concept  is  designed  for  loosely-coupled  structures.  It  transfers 
messages  via  links,  such  as  serial  or  parallel  point-to-point  lines  or  local  area  net¬ 
works. 


Task  interactions 


coMMiicotion 

conetfH 

iingU  producar 
aingla  conaumor 

aingla  praducar 
autfipto  cantu—r 

•uIMpit  ptMuctr 
liigltMutNpIt  Ofinwr 

taal.-tak-Mfid 

X 

(XI 

tanti-liMKatHin  -  MM 

X 

(X) 

SynchronizaHon-amm 

X 

X 

X 

X 

X 

X 

X  ::<Fu«»u»port 
(X I ::  a  Partial  support 

TABLE  1  :  TASK  INTERACTIONS  SUPPORT  OF  COMMUNICATION  CONCEPTS 

The  concepts  "synchronlzation-send*  and  "no-^wait-send"  support  all  task  Inter¬ 
actions  necessary  In  distributed  architectures.  Thus,  they  can  be  generally  used  to 
execute  task  interactions  in  distributed  machines.  The  different  forms  of  implementa¬ 
tion  in  software  and  hardware  are  still  to  be  examined  with  respect  to  realization 
efforts  and  transfer  efficiency. 

Hulti-access  structures,  e.  g.  mail  boxes,  shared  memories  and  similar  structures, 
which  are  necessary  for  the  "synchronization-send"  concept,  are  passive  objects  of  com¬ 
munication  and  require  great  administration  efforts  from  the  software.  The  accesses  of 
producer  and  consumer  tasks  to  the  passive  objects  have  to  be  handled  by  synchroniza¬ 
tion  aids  of  the  tasks  or  special  software,  e.  g.  semaphores  or  monitors.  The  adminis¬ 
tration  effort  necessary  is  complex  and  impedes  the  real-time  behavior  of  the  tasks. 
Furthermore,  it  cannot  be  reduced  by  efficient  forms  of  implementation.  However,  the 
links  of  the  "no-walt-send"  concept,  in  various  forms  of  Implementation,  can  be  real¬ 
ized  as  passive  or  active  objects  of  communication  in  distributed  architectures.  In 
case  they  were  realized  as  active  objects,  this  permits  the  design  of  an  autonomous 
communication  system.  The  communication  system  has  to  carry  out  the  following  autono¬ 
mous  functions: 

a)  Message  Setup 

The  producer  task  delivers  the  message  to  the  link  of  its  node,  Initiates  it  and 
then  continues  the  task  run  (no*vait*send).  Further  messages  can  be  delivered  inde¬ 
pendently  of  the  message  transfer.  Number  and  size  are  limited  by  the  physical 
realization. 

b)  Message  Transmission 

The  link  transmits  the  message  in  a  name-oriented  manner  via  an  unidirectional  com¬ 
munication  channel  switched  as  a  point-to-point  line  or  local  area  network. 

c)  Message  Receipt 

All  receivers  connected  to  the  link  detect  (filter)  the  message  name  (entry  name) 
and  -  if  they  accept  the  message  -  receive  it  for  the  consumer  tasks  of  their 
nodes. 

d)  Message  Delivery 

The  receivers  check  the  messages  received  and  handle  them  independently  of  the  con¬ 
sumer  tasks.  The  messages  can  be  processed  according  to  type  and  then,  depending  on 
the  type,  delivered  directly  or  on  request  to  the  consumer  tasks  of  the  nodes. 

The  "no-wait-send"  communication  concept  is  the  most  effective  one  of  the  four  con¬ 
cepts  examined.  The  functional  structure  of  the  concept  depicted  above  is  data-flow- 
oriented  and  represents  a  complete  autonomous  comDunicatioii  system.  This  guarantees  a 
mlnlmallzation  of  the  administration  efforts  on  the  task  and  software  side.  This  is  the 
case  because  the  software  effort  for  task  interactions  is  reduced  to  mere  deliver  and 
receive  actions  of  the  producer  and  consumer  tasks. 

In  order  to  guarantee  run  conditions  defined  within  the  distributed  architecture 
and  in  order  to  achieve  the  necessary  flexibility  for  programming,  the  types  of  mes¬ 
sages  for  real-time  applications  have  to  be  defined  In  the  following.  They  have  to  be 
compatible  with  the  syntax  of  the  Ada  reference  manual  /8/.  Furthermore,  experience 
gained  from  real-time  applications  and  examinations  of  them  require  the  real-time  mes¬ 
sages  to  be  classified  into  types. 

In  the  suggested  distributed  machine  architecture  of  embedded  computer  systems  a 
set  of  messages  structured  In  data  messages  and  system  messages  Is  defined  for  task 
Interactions.  Table  2  shows  the  defined  set  of  messages.  All  types  of  messages  are 


transaltted  via  the  autonoaoua  couunication  syatea.  Fig,  3  shows  the  Infornation  for- 
nats  of  the  messages  to  be  transmitted. 


Messages 


OotQ  messages 

Systan  messoges 

^rpe  Stale  data 

EvenI  data 

Eipirahoft  dota 

Type:  SynchriMNtofioA  promise 

EiceptNm  handling  request 

Abort  request 

TABLE  2.  TYPES  OF  MESSAGES 


Both  information  formats  of  itessages  start  with  the  name  of  the  message.  The  name 
refers  to  names  of  entry  declarations  in  Ada  programs.  The  name  helps  the  receivers  to 
detect  (filter)  the  messages  addressed  to  the  consumer  tasks  of  their  nodes. 

System  messages  contain  the  name  of  the  current  action  only.  The  receivers  transfer 
the  names  of  system  messages  received  directly  to  the  consumer  tasks  of  their  nodes. 
After  receipt,  the  tasks  start  the  program  actions  to  be  allocated  to  the  names  of 
system  messages. 

Data  messages  transfer  parameters  of  the  Ada  entry  calls  and,  in  addition  to  the 
name  representing  a  task  entry  in  consumer  tasks,  contain  the  data  and  details  about 
the  type  and  the  length  of  the  data.  The  latter  information  serves  for  controlling  pur¬ 
poses  for  the  receivers  of  the  communication  system.  The  type  of  data,  however,  is  an 
administrative  information  for  the  receivers.  It  determines  how  the  data  received  are 
to  be  treated.  Data  messages  transfer  parameters  of  the  Ada  entry  calls  as  "state 
data",  "event  data"  or  "expiration  data"  in  the  distributed  architecture. 


DATA  MESSAGE : 


1  .  1  Oita 

lum 

type 

1’  1  ma»756byte  |  1 

nomt  ::«(tQsli.nomt.]«nfqr.nemt 
type  ; : «  state  I  event  lenpirotion 
length :: «  number,  of. dots. bytes 


SYSTEM  MESSAGE; 


nome  :  a  task.name  I  systeeuMssoge 

system. aetsogc  ::a(tosfi.name.Isystem.mess(i9e.*dentif(er 
system.messoge.  idmttifier  ; :  a  entry. name  t  eiception.  nome 

FIGURE  3:  INFORMATIONFORMATSOF  MESSAGES 


"State  data"  are  state  values  of  the  embedded  computer  systm  or  its  environment 
related  to  a  time  interval.  This  time  interval  is  determined  by  the  cycle  time  of  the 
producer  task  which  updates  the  data.  Consumer  tasks  can  accesu  to  the  values  of  the 
"state  data"  as  often  as  they  wish.  Old  values  of  "state  data"  stored  in  the  receivers 
are  overwritten  by  new  values  to  "state  data”  (same  name)  of  the  producer  tasks. 

An  example  of  a  typical  "state  data"  message  is  the  time  often  required  in  real¬ 
time  applications.  In  the  distributed  architecture  a  producer  task  centrally  updates 
the  time  every  second  and  sends  the  updated  values  of  the  parameters  SEC,  MIN,  HOUR, 
DAT,  etc.  as  "state  data"  messages  to  the  receivers  of  the  consumer  tasks.  They  can 
interrogate  the  time  from  the  receivers  of  their  nodes  as  often  as  they  wish,  as  they 
are  handled  as  "state  data". 

"Event  data"  report  about  certain  (single)  values,  as  e.  g.  about  a  certain  mea¬ 
sured  value  or  a  certain  character.  The  values  of  "event  data”  messages  store  receivers 
for  single  accesses  of  the  consumer  tasks.  After  a  read  access  by  a  consumer  task  to  a 
current  value  of  "event  data",  the  value  in  the  receiver  of  the  task's  node  becomes 
Invalid  and  is  no  more  available  to  further  read  accesses.  Upon  read  accesses,  the 
stored  follow-up  values  of  "event  data"  (same  name)  deliver  receivers  to  consumer  tasks 
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of  their  nodes  in  first-ln*flrst»out  order.  The  values  of  "event  data"  stored  In  the 
receivers  are  only  overwritten  by  new  values  to  "event  data"  (same  name)  of  the  pro¬ 
ducer  tasks,  if  they  became  Invalid  after  read  accesses. 

Typical  "event  data*  messages  are,  e.  g.,  parts  of  ordered  data  streams,  such  as 
sequences  of  characters,  which  supply  the  correct  results  only  If  they  are  executed  or 
evaluated  in  the  correct  order.  Values  of  messages  agreed  as  "event  data"  buffer  and 
transfer  receivers  to  the  consumer  tasks  of  their  nodes  In  the  correct  order.  Thus  the 
receivers  handle  the  data  buffers  of  the  "event  data”  messages  for  the  consumer  tasks. 

"Expiration  data"  are  values  of  the  embedded  computer  system  or  its  environment 
valid  only  for  a  limited  period  of  time.  Within  their  lifetime,  the  values  of  "expira¬ 
tion  data"  can  be  accessed  to  by  consumer  tasks  as  often  as  they  wish.  The  receivers 
autonomously  control  the  lifetime  of  the  values.  It  can  be  set  and  may  amount  to  a 
multiple  of  a  basic  time  clock.  This  handling  is  limited  by  the  physical  realization. 
Valid  and  invalid  values  of  "expiration  data"  stored  in  the  receivers  are  overwritten 
by  new  values  to  "expiration  data”  (same  name)  of  the  producer  tasks.  By  doing  so  the 
lifetime  of  the  values  is  initialized  again  in  the  receivers. 

Values  that  can  only  be  correctly  executed  or  evaluated  within  their  lifetime, 
which  is  determined  by  signals  allocated  to  the  values,  are  typical  "expiration  data” 
messages . 

The  distributed  machine  described  in  /II/  uses  a  similar  concept  to  transfer  and 
handle  the  messages  of  task  interactions. 


THE  MCHITBCTOItB  Of  OISTEIBOTBD  MCSIVBS 

The  suggested  distributed  machine  consists  of  a  cluster  of  subsystems  cooperating 
with  each  other  and  realized  in  VLSI-technology  and  a  communication  system  connecting 
the  subsystems  with  each  other  in  a  flow-oriented  way.  Fig.  4  shows  the  general  struc¬ 
ture  of  this  cluster. 

A  subsystem  la  a  hardware  and  software  unit  carrying  out  a  complete  task  in  paral¬ 
lel  to  the  tasks  of  other  subsystems  of  the  cluster.  A  subsystem  consists  of  a  proces¬ 
sor  node  including  comaunioation  units  and  the  total  software  the  task  needs  to  carry 
out  its  activities. 
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figure  4 :  CLUSTER 


In  the  suggested  distributed  architecture  a  processor  node  is  a  hardware  unit  con¬ 
sisting  of  at  least  the  VLSI  components  microcomputer  (processor  with  memory)  and  com¬ 
munication  unit.  Depending  on  application  the  processor  node  can  be  expanded  by  further 
communication  units  and  a  process  Interface,  which  -  if  required  -  permits  sensors  and 
actuators  to  be  coupled  to  processor  nodes  to  measure  and/or  generate  signals.  Fig.  5 
shows  the  general  structure  of  a  processor  node. 

The  coonunicatlon  system  of  the  architecture  can  be  regarded  as  a  network  of  loose¬ 
ly  coupled  communication  units  and  links  which  -  in  a  flow-oriented  way  -  are  switched 
as  unidirectional  point-to-point  lines  and/or  local  area  networks.  It  consists  of  the 
following  assemblies: 

o  Communication  units  of  the  processor  nodes.  The  structure  of  a  ccxamunication  unit  is 
shown  in  fig.  6. 

o  Communication  channels. 
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FIGURE  5:  PROCESSOR  NODE 


The  communication  unit  conaiata  of  a  tranamltter  unit  and  a  receiver  unit.  Both 
unlta  are  coupled  to  a  proceaaor  node  and  work  Independently  of  each  other. 

The  producer  taak  haa  to  Inform  the  transmitter  unit  about  the  name,  type  and 
length  of  each  meaaage  in  order  to  be  able  to  transmit  the  messages  of  task  inter- 
actions  autonomously.  Upon  receipt  of  this  information  the  transmitter  unit  starts  the 
autonomous  message  transfer  of  the  communication  channel  connected. 


TRANSMITTER  UNIT 


PROCESSOR  NODE  INTERNAL  BUS 

RECEIVER  UNIT 


FIGURE  6:  COMMUNICATION  UNIT 


The  program  has  to  inform  the  receiver  unit  about  all  names  of  the  messages  which 
can  be  transmitted  to  the  consumer  task  of  its  processor  node  in  order  to  be  able  to 
receive  messages  of  the  task  interactions  autonomously.  With  the  help  of  the  list  of 
names  the  receiver  unit  detects  (filters)  the  messages  of  the  communication  channel 
connected.  It  accepts  messages  with  names  from  the  communication  channel  which  the  con¬ 
sumer  task  of  its  processor  node  accepts  as  well.  The  receiver  unit  transmits  system 
messages  accepted  directly  to  the  consumer  task  via  the  system  message  buffer.  Data 
messages,  however,  are  stored  and  processed  by  the  receiver  unit  in  the  data  RAN  disk 
for  read  accesses  of  the  consumer  task. 

The  communication  network  is  switched  in  a  flow-oriented  way.  This  means,  the  sug¬ 
gested  distributed  machine  architecture  does  not  execute  task  interactions  via  univer¬ 
sal,  system-oriented  communication  channels,  but  rather  via  application-oriented  chan¬ 
nels  switched. 

The  following  links  are  available  for  the  realization  of  distributed  machine  archi¬ 
tectures;  they  can  be  designed  with  the  help  of  Ada  language  corstructs,  as  shown  in 
the  chapter  "Communication  Model  in  Ada",  and  have  been  realized  in  the  form  of: 

o  Private  communication  channels,  point-to-point  lines  between  a  transmitter  and  a 
receiver; 

o  global  communication  channels,  local  area  networks  between  one  or  several  transmit¬ 
ters  and  one  or  several  receivers. 
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Fig.  7  shows  forms  of  the  unidirectional  communication  channels  permitted  in  the 
suggested  distributed  architecture. 


a)  Private  communication  duinnel 

Pmnf*  Imeltnt  ffOMmittir.ont  rtctiver} 


b|  Global  communication  channel 

Local  orta  notwork  (on«  tronsmittor-mulhpic  rccatvtrt) 


c)  Global  communication  channel 

Local  OTM  nohiork  ( mulhplo  ffonsmittors-ono/mulHplo  rccoivcri) 


FIGURE?.  COMMUNICATION  CHANNELS 


Private  communication  channels  transmit  messages  between  a  producer  and  a  consumer 
task.  The  polnt-to^polnt  lines  of  the  channels  directly  correspond  to  task  inter* 
actions (  the  actions  of  which  in  Ada  programs  represent  an  entry  of  a  consumer  task  and 
an  entry  call  of  a  producer  task,  each  of  the  same  name. 

Global  communication  channels  transmit  messages  between  several  tasks. 

0  Being  occupied  by  a  transmitter  and  several  receivers,  global  connunlcatlon  channels 
transmit  messages  between  a  producer  task  and  several  consumer  tasks.  The  local  area 
networks  of  the  channels  directly  correspond  to  task  interactions,  the  actions  of 
which  in  Ada  programs  represent  entries  (same  name)  of  several  consumer  tasks  and  an 
entry  call  of  a  producer  task  affecting  these  entries. 

0  Being  occupied  by  several  transmitters  and  one  or  several  receivers,  global  communi¬ 
cation  channels  transmit  messages  independent  of  each  other  of  several  producer  tasks 
to  one  or  several  consumer  tasks.  The  local  area  networks  of  the  channels  directly 
correspond  to  task  interactions,  the  actions  of  which  in  Ada  programms  represent 
entry  families  (same  name)  of  one  or  several  consumer  tasks  and  the  entry  calls  of 
several  producer  tasks  affecting  the  distinct  entries  of  the  families. 


CONMOIIICATIOir  HODBL  IN  ADA 

The  task  interactions  to  be  executed  in  the  suggested  distributed  machine  architec¬ 
ture  are  be  designed  and  documented  as  transparent  software  and  hardware  allocations  In 
Ada  programs.  For  this  purpose  the  syntax  and  semantics  for  tasks  and  task  interactions 
determined  by  Ada  is  to  be  checked  and,  if  necessary,  to  be  adapted  to  the  operating 
conditions  of  the  suggested  distributed  machine  architecture. 

Ada  /8/,  /9/,  /10/  defines  tasks  as  concurrent  program  units  working  on  their  own 
’’logic  processors"  independently  of  other  tasks,  except  for  points  of  synchronization. 

This  ideal  definition  for  the  implementation  of  the  suggest sd  distributed  machine  is  • 

restricted  by  the  "parent-child"  dependence  of  the  concurrent  progam  units,  e.  g.  i 

between  the  main  program  (master)  and  all  tasks  or  between  one  parent  task  and  its  I 

children  tasks.  The  semantics  of  the  task  dependence  requires  that  all  tasks  either  be 
started  after  the  master  and  children  tasks  after  their  parent  tasks  or  that  they  be  ! 

terminated  before  them.  It  is  to  be  examined  whether  this  task  dependence  which  is  use-  | 

ful  in  single  processor  systems  can  be  applied  in  an  analog  way  by  the  distributed 
architecture. 

Data  message  transfers  of  task  interactions  are  controlled  as  synchronous  communi¬ 
cation  procedures  by  Ada  by  methods  of  "rendezvous  technology".  Fig.  6  depicts  the 
language  constructs  to  describe  a  rendezvous.  In  Ada  tasks  execute  data  transfers  of 
taks  interactions  via  an  entry  call  of  the  producer  task  and  an  accept  statement  of  the 
consumer  task  to  an  entry  of  the  same  name.  After  execution  of  the  statements  contained 
in  the  accept  statement  of  the  consumer  task  the  rendezvous  is  dissolved  and  the  tasks 
continue  their  activities  in  parallel. 
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FIGURE  6:  STATEMENTS  OF  ADA  TASK  INTERAaiONS 


In  Ada  programs  the  data  transfer  of  a  task  interaction  in  the  producer  task  is 
noted  as  an  entry  call  in  the  form  of  a  subprogram  call.  Return  parameters  are  permit¬ 
ted.  The  are  calculated  or  generated  within  the  rendezvous  by  the  consumer  task  analog 
to  the  subprogram  technology  and  then  transmitted  back  to  the  producer  task.  The  con¬ 
sumer  task  accepts  the  task  Interaction  with  an  accept  statement.  This  statement  must 
calculate  or  generate  the  return  parameters  with  the  help  of  it's  internal  sequence  of 
statements.  Thus  the  Ada  rendezvous  technology  also  permits  the  compulsory  sequentiali- 
zation  of  parallel  program  units.  Programming  and  control  possibilities  using  the 
statements  of  the  universal  Ada  rendezvous  technology  are  to  be  determined  for  the  task 
interactions  in  the  suggested  distributed  machine  architecture. 

The  basic  form  of  the  Ada  data  transfer  rendezvous  can  be  designed  with  the  help  of 
the  language  constructs  outlined  in  fig.  8.  Tasks  executing  an  entry  call  or  an  accept 
statement  in  the  basic  form  of  the  rendezvous  wait  for  synchronization  with  the  task 
taking  part  in  the  rendezvous.  If  there  is  no  synchronization,  the  tasks  will  stay  in  a 
wait  state  and  are  blocked.  This  situation  is  monitored  and  controlled  by  Ada  with 
additional  selective  constructs  shown  in  fig.  9* 

Selective  constructs  give  alternatives  to  run  for  rendezvous  that  cannot  take 
place.  The  will  be  executed  in  case  producer  or  consumer  tasks  cannot  be  synchronized 
with  the  tasks  taking  part  in  the  rendezvous.  In  the  selective  construct  the  "delay 
alternative"  defines  the  maximum  time  tasks  should  wait  for  synchronization  so  that  a 
rendezvous  can  take  place.  If  there  is  no  "delay  alternative"  in  a  selective  construct, 
alternatives  are  started  to  run  immediately,  in  case  the  language  constructs  Initiating 
the  rendezvous  do  not  synchronize  the  tasks. 

System  message  transfers  of  task  interactions  are  controlled  by  Ada  by  methods  of 
various  communication  procedures.  Synchronization  promises,  like  data  messages,  are 
transmitted  by  methods  of  synchronous  comaunlcation  procedures.  Requests  for  exception 
handling  and  abort  requests  are  to  be  noted  in  producer  tasks  by  means  of  specific 
constructs.  The  requests  are  transmitted  in  asynchronous  mode.  In  consumer  tasks  the 
requests  initiate  the  immediate  execution  of  the  actions  requested,  as  e.  g.  exception 
handling;  EXCEPTION_FLIGHT_CONTROL. 
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FIGURE  9  :  SELECT  STATEMENTS  OF  ADA  TASK  INTERACTIONS 


Ada  programs  must  be  transparent  and  transferrable  to  the  architecture  as  suggested 
in  the  chapter  "The  Architecture  of  Distributed  Machines".  It  is  to  be  checked  which 
restrictions  and/or  expansions  are  necessary.  By  doing  so,  the  following  aspects  of 
paralleling  and  controlling  are  to  be  considered: 

*  0  The  task  dependence  is  given  Implicitly  by  the  communication  system  of  the  architec¬ 

ture. 

0  Task  interactions  are  not  directly  carried  out  in  synchronous  mode  between  the  tasks, 
but  rather  indirectly  in  asynchronous  "shared  rendezvous"  mode  via  the  active  com¬ 
munication  system  of  the  architecture. 

o  The  communication  units  (transmitters  or  receivers)  of  the  communication  system  are 
rendezvous  partners  of  the  producer  and  consumer  tasks  in  the  "shared  rendezvous" 

^  mode.  The  units  accept  or  deliver  the  messages  unldlrectionally. 

f  o  All  task  interactions  are  to  be  noted  in  Ada  constructs  taking  into  account  the  uni¬ 

directional  flow  in  the  communication  channels  of  the  architecture.  Thus,  the  modes 
"out"  and  "in  out"  are  not  permitted  in  the  formal  part  of  the  entry  call  and  the 
accept  statements.  This  is  the  only  restriction  required  by  architecture,  as  against 


o  The  message  types  EVENT,  STATE  and  EXPIRATION  of  the  task  interactions  are  to  be 
specified  by  compiler  instructions  (pragmas)  as  instructions  to  the  data  administra¬ 
tion  of  the  communication  system.  The  syntax  is  shown  in  fig.  10. 

o  The  same  entry  names  in  tasks  are  necessary  to  design  global  communication  paths. 

/8/  does  not  explicitly  prohibit  this  definition.  The  manual  does  not  provide  a  clear 
statement  on  this  matter. 

An  analysis  of  the  Ada  syntax  showed  that  in  addition  to  the  transfer  restriction 
of  task  interactions  to  the  mode  "in"  only  the  compiler  instructions  depicted  in 
fig.  10  are  necessary  to  port  Ada  progr^s  to  the  distribu..ed  machine  architecture. 
Transparency  can  be  guaranteed  by  the  autonomous  communication  system. 


* 
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MESSAGE  TYPE  SaECTION :  _ 
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DECURATION  OF  MESSAGE  TYPES  IN  ADA  PROGRAMS- 


FIGURE  10:  SYNTAX  OF  MESSAGE  TYPE  SELECTION 


Depending  on  the  operational  requirements  to  be  net  by  the  embedded  computer  sys* 
tens  and  in  accordance  with  the  Ada  reference  manual  /6/  the  following  runtime  condl* 
tions  must  be  realiaed  in  order  to  be  able  to  efficiently  execute  concurrent  actions  of 
tasks  in  the  suggested  distributed  architecture: 

o  Waiting  for  initialization 

o  Activation  (runtime) 

o  Wait  for  synchronization  promise 

0  Execution  of  exceptions 

o  Termination  with  execution  of  task-specific  exception  handler 


Pig.  11  shows  the  runtime  conditions  of  the  tasks.  All  tasks  start  initializing  the 
embedded  computer  system.  As  long  as  they  are  not  waiting  for  synchronization  promises, 
they  execute  their  actions  independently  of  each  other.  They  execute  task  interactions 
as  producer  or  consumer  tasks  in  "shared  rendezvous"  mode  by  corresponding  transmitters 
or  receivers  of  the  connunication  units  of  their  processor  nodes.  They  deliver  the  mes¬ 
sages  to  transmitters  and  accept  them  from  receivers  of  the  communication  system  in 
asynchronous  mode.  They  only  get  synchronized  with  the  transmitters  or  receivers  of  the 
autonomous  communication  channel  of  the  distributed  architecture  which,  parallely  to 
the  task  run,  transmits  and  handles  the  messages.  Pig.  12  shows  the  structure  of  the 
"shared  rendezvous"  mode. 
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FIGURE  12:  SHARED  RENDEZVOUS  MODE 


The  appllcatlon-apeciflc  coniBunication  network  of  the  distributed  architecture 
necessary  to  carry  out  the  task  interactions  is  descrlbable  in  Ada  prograns.  There, 
entry  declarations  represent  the  cosHBunication  channels  of  the  distributed  architect- 
ture.  The  entry  names  of  the  declarations  define  the  communication  network  of  the  task 
interactions,  applying  the  following  rules: 

o  One  entry  name::: 

Point-to-point  lines  between  one  consumer  and  one  producer  task  (private  communica¬ 
tion  channel ) . 

o  Several  identical  entry  names::s 

Local  area  network  between  several  consumer  and  one  producer  task  (global  communi¬ 
cation  channel). 

o  One  or  several  Identical  entry  families 

Local  area  network  between  one  or  several  consumer  tasks  and  one  or  several  pro¬ 
ducer  tasks  (global  cooununlcatlon  channel). 

An  expansion  by  the  attribute  task  name  of  the  allocation  rules  outlined  condenses 
the  communication  networks  designed  on  the  basis  of  entry  names  by  multiple  use  of  the 
communication  channels,  namely  sequential  task  Interactions. 

In  the  suggested  distributed  architecture  the  tasks  get  terminated  independently  of 
each  other.  The  task  dependence  required  by  Ada  handles  the  communication  system  of  the 
architecture.  It  buffers  the  messages  of  producer  tasks  already  terminated  and  delivers 
them  to  consumer  tasks  still  activated. 


EIMPIES  OP  TA3X  INTBRACTIOIIS 

AND  DISTRIBUTED  HACHINE  ARCHITECTURES 

The  suggested  distributed  architecture  transmits  messages  of  task  interactions  via 
private  and  global  communication  channels  with  definite  software  and  hardware  alloca¬ 
tion.  This  statement  is  confirmed  by  the  following  examples: 

a)  Task  interactions  between  one  producer  and  one  consumer  task: 

The  message  transfers  are  executed  by  the  conmunicatlon  network  having  private  com¬ 
munication  channels  (point-to-point  lines).  Fig.  ^3  Shows  an  example  of  the  soft¬ 
ware  and  hardware  allocation  of  these  task  interactions.  In  this  example  an  "event 
data"  message  is  transmitted.  The  example  also  contains  the  necessary  type  declara¬ 
tion  of  the  message. 
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FIGURE  13:  TASK  INTERAaiON  BETWEEN  ONE  PRODUCER  TASK  AND  ONE 
CONSUMER  TASK 


b)  Task  Interactions  between  one  producer  task  and  several  consumer  tasks: 

The  message  transfers  are  executed  by  the  communication  network  having  global  com¬ 
munication  channels  (local  area  networks).  Pig.  14  shows  an  example  of  the  software 
and  hardware  allocation  of  these  task  interactions.  In  this  example  a  "system"  mes¬ 
sage  (synchronization  promise)  is  transmitted.  The  type  of  this  message  is  already 
determined  and  does  not  have  to  be  explicitly  declared  in  the  program. 
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FIGURE  14 :  TASK  INTERAaiON  BETWEEN  ONE  PRODUCER  TASK  AND 
MULTIPLE  CONSUMER  TASK 


c)  Task  interactions  between  one  or  several  producer  tasks  and  one  or  several  consumer 
tasks : 

The  message  transfers  are  executed  by  the  communication  network  having  global 
communication  channels*  as  shown  in  fig*  14.  Deviating  from  the  example  shown  in 
fig.  14,  in  this  communication  mode  one  or  several  producer  tasks  transmit  messages 
of  the  task  interactions  to  distinct  entries  of  entry  families  of  one  or  several 
consumer  tasks. 


d)  Structure  of  a  task  network: 


Fig.  15  shows  the  structure  of  a  guidance  i  control  software  implemented  as  a 
distributed  system  according  to  the  specifications  made  in  this  suggestion. 


FIGURE  IS:  EXAMPLE  OF  MISSILE  GUIDANCE  ft  CONTROL  SYSTEM 
REALIZED  IN  DISTRIBUTED  MACHINE  ARCHITECTURE 


DESIGN  AND  OOCOHBNTATION  TOOLS 

An  APSE,  consisting  of  the  MAPSE  tools  and  program  abstraction  tools,  such  as 
PAMELA  /12/  or  Buhr  Design  Method,  and  runtime  analysls/communioation  simulator  are 
necessary  for  the  computer-aided  support  of  the  implementation  of  Ada  programs  on 
application-oriented  distributed  architectures.  The  tools  must  support  the  separation 
of  the  tasks  as  complete  loadable  and  operable  program  units.  They  must  automatically 
generate  and  check  the  names  of  the  flow-oriented  message  transfers  of  task  inter¬ 
actions  in  all  operating  levels  and  for  all  separated  tasks. 


FfGURE  16 ;  ADDITIONAL  TOOLS  FOR  COMMUNICATION  AND  NETWORK  DESIGN 


The  entry  call  for  task  interactions  defined  by  Ada  is  to  be  accepted  by  the  tools 
only  unidirectionally  in  mode  "in".  As  far  as  the  handling  of  the  data  flows  of  task 
interactions  by  the  hardware  is  concerned,  i.  e.  the  comDunication  system  of  the  sug¬ 
gested  distributed  architecture,  the  compiler  Instructions  (pragmas)  STATE,  EVENT  and 
EXPIRATION  are  to  be  checked  and  executed  additionally.  The  shared  variables  permitted 
by  Ada  are  generally  uneffective  in  distributed  architectures  and  therefore  must  not  be 
supported  by  the  tools. 
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CONCLOSIOIl 

Ada  language  constructs  are  a  valuable  implementation  tool  to  execute  task  inter¬ 
actions  In  embedded  computer  systems  realized  as  distributed  machines  according  to  the 
suggested  concept  of  architecture.  Once  the  semantics  has  been  clearly  defined,  the  Ada 
constructs  can  be  used  to  design,  program  and  implement  application-oriented  distrib¬ 
uted  architectures  for  real-time  applications  with  direct  hardware  and  software  alloca¬ 
tion.  The  suggestion  outlined  confirms  this. 
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DISCUSSION 


WManseUGe 

To  realize  your  “No- Wait-Serial”  task  interactioo  mechanization  will  probably  need  some  mechanism  which  might  be 
realized  by  special  I/O  processes.  Can  you  comment  on  this? 

Author’s  Reply 

The  I/O  processes  of  producer  tasks  are  entry-calls  of  mode  “in”  in  accord  with  the  Ada  reference  manual.  A  producer 
task  calls  the  transmitter  of  its  node  and  initiates  the  transmitter.  The  I/O  processes  of  consumer  tasks  are  accept 
actions  in  accord  with  the  Ada  reference  manual.  A  consumer  task  calls  the  receiver  of  its  node  to  deliver  the  specified 
message. 


C.Berggren,  US 

Is  this  a  concept  only  or  have  you  actually  implemented  it?  Does  your  development  map  onto  military  standards 
intended  for  task  communications  in  future  embedded  distributed  systems? 

Author’s  Reply 

The  concept  outlines  the  result  of  a  study  which  analyzed  the  problems  of  task  interactions  in  distributed  architectures. 
The  result  of  the  study  is  a  proposal  which  describes  the  structures,  the  functions  and  the  functional  layers  of  a  powerful 
autonomous  communication  system  usable  in  distributed  architectures  and  the  adaptation  of  this  system  to  the  program 
language  Ada.  The  adaptation  of  general  ccsnmunication  and/or  protocol  standards  is  part  of  a  future  project  phase. 
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FUNCTIONAL  PflOGRAMHlHG  LANGUAGES  AND  MODERN 
MULTIPROCESSOR  ARCHITECTURES:  THE  EMSP  EXAMPLE 

J.  DENNIS  SEALS 

GERALD  U.  GRUBE 

Bell  Laboratories 
Whippany,  New  Jersey  07981 

Suaaaryt  Future  nllitary  systens  will  require  a  mix  of  signal,  data,  and 
oonti^ol/deolslon  processing  at  throughput  levels  ranging  from  0*1  to  4  billion 
operations  per  second.  Estiaates  of  the  eabedded  software  to  support  these  systems  range 
from  0*5  to  10  million  lines  of  code.  Early  in  the  1980,  the  Navy  recognized  the 
severity  of  these  problems  and  awarded  ATAT  Bell  Laboratories  a  contract  to  design  a 
revolutionary  new  computer  architecture  that  would  meet  their  signal  processing  needs 
through  the  year  2000.  The  result  was  the  EMSP  architecture  that  combines  the 
programming  simplicity  of  a  functional  language  with  the  power  of  a  modular,  scalable, 
heterogeneous  multiprocessor.  The  glue  that  binds  these  two  attributes  is  a  data-flow 
control  mechanism  that  provides  a  transparent  interface  between  the  application  user  and 
the  machine  hardware.  This  paper  will  report  on  this  successful  integration  of  a 
functional  graph  language  and  a  multiprocessor  architecture. 

Index  Terms  -  Multiprocessing,  Data-flow,  Graphical  Languages,  Functional  Languages 

I.  Introduction  -  The  Problem 

The  requirement  on  future  military  systems  to  detect,  engage,  and  defeat  threats  at  ever 
increasing  ranges  and  under  hostile  environments  places  unprecedented  demands  on  the 
processing  systems.  The  increased  sensitivity  and  resolutions  of  new  sensors,  the  need 
for  low  false  alarm  rates,  and  complex  fusion/asset  management  algorithms  demand  a  mix 
of  signal,  data,  and  decision  processing  at  throughput  rates  that  can  easily  exceed  one 
billion  operations  per  second.  These  requirements  are  forcing  computer  architects  to 
come  to  terms  with  two  extremely  difficult  problems  -  (1)  designing  a  modular,  scalable 
heterogeneous  multiprocessor,  and  (2)  developing  a  methodology  for  programming,  testing 
and  supporting  embedded  software. 

The  need  for  a  multiprocessor  architecture  is  readily  derived.  There  is  no  existing  or 
proposed  uniprocessor  that  is  capable  of  the  required  throughput.  Even  if  such  a  feat 
were  technically  possible,  it  would  have  drawbacks  from  the  standpoint  of  scalability 
and  fault-tolerance.  Since  data,  signal,  and  symbolic  processing  have  their  own  special 
hardware  requirements,  it  is  clear  that  a  heterogeneous  architecture  will  be  required. 
Unfortunately,  complex  multiprocessor  architectures  have  been  notoriously  difficult  to 
program,  and  that  brings  us  to  the  second  problem  -  software. 

Estimates  of  the  embedded  software  required  to  support  programs  such  as  ATA,  ATF,  and 
LHX  range  from  0.5  to  10  million  lines  of  code.  Current  estimates  for  the  cost  of 
developing  a  line  of  high  level  code  for  embedded  programs  range  between  $200  and  $2000. 
A  500,000  line  program  may  require  over  500  staff-years  to  develop  and  test.  But  this  is 
only  one  part  of  the  software  problem.  The  cost  of  maintenance  and  support  can  represent 
as  much  as  80%  of  the  life-cycle  cost.  Simple  arithmetic  shows  that  future  software 
projects  could  cost  billions  of  dollars  unless  new  approaches  are  found  to  mitigate 
development,  test,  and  support  costs. 

In  this  paper,  we  will  present  an  architecture  (language,  compilers,  run-time 
executives,  and  machine  hardware)  that  meets  these  requirements  and  substantially 
reduces  software  cost.  The  machine  described  is  not  a  laboratory  curiosity,  but  a  fully 
supported,  mil-qualified  production  system. 

II.  System  Concept  -  Designing  the  Next  Generation  Architecture 

In  early  1980,  the  U.S.  Navy  recognized  that  a  revolutionary  new  approach  to  processing 
and  software  development  was  needed  to  meet  future  embedded  processing  requirements. 
They  awarded  ATAT  Bell  Laboratories  a  contract  to  create  a  new  generation  of  computer 
architecture  called  the  Enhanced  Modular  Signal  Processor,  EMSP  [1].  The  design  goal 
for  the  project  was  straightforward  -  design  a  multiprocessor  architecture  that  would 
meet  the  Navy's  signal  processing  requirements  through  the  year  2000,  while 
significantly  reducing  software  development  and  support  costs.  Implicit  in  this  goal 
was  the  need  for  an  open  architecture  that  was  scalable  from  a  few  processing  elements 
to  tens  of  processing  elements  to  encompass  the  range  of  applications.  The  architecture 
had  to  retain  software  and  system  compatibility  across  all  configuration,  and  provide  a 
highly  fault  tolerant  and  supportable  environment. 

In  order  to  meet  this  ambitious  goal,  the  EMSP  design  team  identified  three  major  design 
concepts,  all  departures  from  traditional  processing  architectures.  The  first  concept 
was  the  specification  of  a  functional  graph  language  as  the  means  of  capturing 
applications.  This  approach  permits  the  application  engineer  to  define  the  processing 
and  flow  of  data  as  a  data-flow  program  -  a  kind  of  formalized  and  highly  structured 
flow  chart.  Data-flow  programs  are  directed  graphs,  where  the  graph  nodes  represent 
processing  functions,  and  the  graph  arcs  represent  the  flow  of  data  or  synchronization 
tokens.  Data-flow  application  graphs  are  not  only  simpler  to  develop  than  conventional 
procedural  programs,  but  they  also  provide  a  natural  paradigm  for  concurrent  processing. 
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This  departure  froB  claaalcal  prograsBing  waa  not  Bade  lightly.  Although  functional 
prograBBing  languages  have  been  around  since  the  I96O81  there  has  been  little  success  in 
achieving  "real  world"  application.  Much  of  the  early  work  focused  on  proving  program 
correctness.  Subsedueot  efforts  addressed  the  use  of  functional  languages  as  a  means  for 
foraal  specification  and  validation  of  prograa  requlreBents.  Recent  work  has  focused  on 
the  use  of  functional  language  as  a  means  of  application  capturei  but  the  results  have 
been  liaited.  One  Bajor  reason  for  the  limited  success  and  slow  acceptance  Is  the 
Incoapatlbillty  between  functional  languages*  and  architectures  developed  for  procedural 
languages. 

This  led  to  the  second  aajor  design  concept*  namely  the  design  of  a  coarse-grain * 
dynamic,  data-flow  control  Bechanlsa  t2]«  This  aechanisa  was  implemented  via  a  run-tiae 
executive  called  the  £MSP  shell.  The  shell  dynaaically  manages  queues  and  schedules 
nodes  to  processors  when  all  node  inputs  are  available.  The  shell  implements  graph  arcs 
as  dynamic  first-in,  first-out  (FIFO)  queues*  and  nodes  as  instruction  streams  -  a  set 
of  proceasing  instructions  specifying  inputs*  outputs,  and  functions  to  be  perforaed. 
When  a  queue  reaches  threshold  (l.e.*  it  has  enough  data  to  execute  a  node),  a  message 
is  sent  to  the  scheduling  function.  When  all  input  queues  for  a  given  node  reach  or 
exceed  threshold*  the  node's  instruction  stream  is  sent  to  any  free  processor  for 
execution.  This  control  aechanisa  naturally  supports  concurrent  processing  on  a 
heterogeneous  multiprocessor.  This  concepts  frees  the  application  user  from  machine 
dependent  functions  such  as  memory  assignment  and  management,  concurrent  task 
scheduling,  and  task  binding. 

The  third  design  concept  was  the  specification  of  a  open,  modular  architecture  that  can 
be  configured  for  a  wide  range  of  applications.  The  machine  architecture  consists  of 
four  basic  eleaents:  a  scheduler*  a  command  processor,  global  memory,  and  node 
processing  elements.  The  command  processor  supports  graph  management,  system  control, 
performance  monitoring,  and  fault  management.  The  scheduler  supports  the  dynamic 
scheduling  and  assignment  of  nodes  to  processing  elements.  The  global  memories  are 
intelligent  repositories  for  for  managing  queues  and  node  instruction  streams. 
Processing  elements  interpert  node  instruction  streams  and  execute  primitive  functions 
on  the  specified  data.  Processing  eleaents  come  in  many  types,  such  as  floating  point 
signal  prooeaaora  t  I/O  processors*  and  data  processors. 

In  the  following  sections  we  will  describe  the  basic  attributes  of  the  graph  language, 
and  show  how  an  application  is  captured  as  a  graph.  A  brief  overview  of  the  functions  of 
the  run-time  executive  ahell  and  machine  architecture  will  be  provided  to  show  their 
interaction  with  the  graph  language. 

III.  The  Graph  Programming  Language 

The  cornerstone  of  the  £KSP  architecture  is  its  functional  programming  methodology.  It 
is  based  on  the  Common  Operational  Software  (COS)  concept  [3]  developed  at  the  Naval 
Research  Laboratory.  This  methodology  separates  the  application  program  into  two 
components:  the  command  program  and  the  application  graph.  The  application  graph  defines 
the  underlying  application  processing*  while  the  command  program  controls  the 
interaction  between  graphs  and  external  I/O. 

The  command  program  controls  the  starting  and  stopping  of  graphs,  external  I/O,  graph 
parameters,  interactions  with  the  pilot  and  other  tactical  systems,  as  well  as  error 
responses  and  processor  status.  For  example,  the  command  program  controls  mode  changes, 
revisit  times,  overload  management,  built-in-test,  and  diagnostics.  It  is  important  to 
note  that  since  the  control  is  not  woven  into  the  fabric  of  the  processing  flow,  it  is 
simple  to  tailor  application  processing  dynamically. 

The  application  graph  is  a  radical  departure  from  classical,  procedural,  programming 
languages  such  as  Fortran,  Ada,  Jovial,  and  C.  It  is  a  functional  language  based  on  the 
directed  data-flow  graph.  This  concept  is  similar  to  the  conventional  flowchart  used  by 
programmers  to  structure  their  code  development*  but  differs  in  two  ways.  First*  the 
structure  is  more  formal  and  rigorous.  Secondly*  the  graph  itself  is  the  program. 

There  are  three  basic  components  to  every  application  graph:  nodes,  queues,  and 
auxiliary  graph  entities.  The  nodes  defines  the  underlying  processing  function  (i.e., 
FFT,  data^merge*  search^tree)  that  is  to  be  performed  on  the  input  data.  Queues  manage 
the  flow  of  lnformation’'betveen  nodes.  Auxiliary  graph  entitles  are  data  structures  that 
are  primarily  used  to  control*  initialize*  or  direct  the  flow  of  information  into  and 
out  of  a  node. 

Nodes  define  the  underlying  application  process,  A  noie  consists  of  three  basic 
components:  a  primitive,  a  primitive  interface  procedure,  and  ports.  The  primitive 
defines  the  processing  function  to  be  performed  on  the  input  data.  It  is  highly  machine 
dependent  code,  and  similar  to  the  private  part  of  an  Ada  package  in  that  it  cannot  be 
modified  by  the  application  user.  The  primitive  interface  procedure  defines  the 
interfaces  between  the  priaitive  and  the  nodes  Inputs.  This  code  is  siallar  to  the 
public  part  of  an  Ada  package.  Ports  are  logical  valves  to  which  data  queues  are 
attached.  They  are  controlled  by  paraaetera  that  determine  when  a  queue  is  to  be 
turned-on  or  turned-off. 

The  queue  provides  the  primary  data  storage  and  transfer  aechanisa  between  two  nodes.  A 
queue  can  be  conceptualized  as  an  elastic  FIFO  buffer.  A  queue  has  one  source  node  that 
produces  (writes)  data  into  the  queue,  and  one  sink  node  that  consumes  (reads)  this 
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data.  Thla  approach  greatly  aispllfles  graph  capture,  and  ensures  that  the  graph  is 
free  froa  slde*effects.  Multiple  copies  of  a  queue  can  be  realized  via  a  replicate  node 
that  produces  eultiple,  Independent  copies.  The  language  recognizes  two  basic  type  of 
queues}  data  queues  and  trigger  queues.  Data  queues  pass  data  that  are  needed  for  the 
underlying  application  process.  Trigger  queues  pass  synchronization  infornation . 

In  addition  to  nodes  and  queues,  one  sore  coaponent  is  needed  is  needed  to  coaplete  an 
application  graph  -  the  auziXiary  graph  entity.  These  coaponents  are  data  structures 
(expressions,  literals,  or  values)  that  specify  paraaeters,  such  as  the  nuaber  of  taps 
in  a  filter,  the  nuaber  of  entries  in  a  threat  file,  or  the  current  operation  aode. 
Auxilliary  graph  entities  fall  into  two  categories:  graph  variables,  and  graph 
instantiation  paraaeters.  Graph  variables  are  expressions  or  literals  that  are  declared 
within  a  graph  or  coaaand  program.  They  can  be  read  or  written  by  the  originating  graph 
or  coaaand  program,  but  its  current  value  can  only  be  read  by  graphs  to  which  they  are 
passed.  Graph  instantiation  parameters  are  constants  that  are  evaluated  at  start  time 
and  passed  by  value  to  a  graph. 

In  the  next  section,  we  will  examine  the  tools  and  techniques  for  the  scheaatlc  capture 
and  compilation  of  application  graphs. 

IV.  Programing  with  Graphs 

The  EHSP  graph  development  tool  set  (see  Figure  1)  provides  a  rich  and  powerful 
environment  for  the  capture,  testing,  documentation,  and  compilation  of  application 
graphs.  It  supports  a  highly  structured  methodology  for  software  development  that 
naturally  partitions  an  application  into  smaller  units  with  well  defined  interfaces. 
This  attribute  permits  the  application  programming  to  be  allocated  to  groups  with 
specialized  talents  and  well  defined  responsibilities. 

The  first  step  in  the  capture  of  an  application  graph  is  its  schematic  capture.  The 
Graphical  Editor  (GRED)  is  a  language»directed.  Interactive  editor  that  enables  the  user 
to  create,  modify,  and  annotate  graph  objects  (subgraphs,  nodes,  queues,  etc.).  It 
supports  a  top-down,  hierarchical  development  in  which  the  development  of  a  high-level 
graph  is  the  first  step.  This  graph  consist  mainly  of  subgraphs,  the  flow  of  information 
among  these  subgraphs,  and  the  system  Interfaces  (see  Figure  3).  The  subgraphs  are 
simply  black  boxes  at  this  stage.  This  top  level  view  of  the  application  is  usually 
defined  by  system  engineers,  who  address  high  level  interactions  and  system  interfaces. 
Once  this  graph  is  completed,  the  subgraphs  are  assigned  and  defined  by  sensor  and 
subsystem  processing  specialists.  Definition  of  each  sensor/subsystem  subgraph  can  be 
carried  out  concurrently  and  Independently.  There  is  no  need  for  the  application 
engineers  to  become  expert  in  high  level  languages  such  as  Ada,  or  to  convey  their 
application  to  a  programmer  who  is. 

Graphs  are  created  on  a  high-resolution,  bit-mapped  terminal.  The  principle  mode  of 
input  is  via  a  three  button  mouse  that  permits  the  user  to  select  graph  objects, 
attributes,  viewing  levels,  and  edit  functions  from  pop-up  menus.  The  keyboard  la 
required  only  for  naming  objects,  graph  fllea,  or  filling  in  templates.  The  graph 
capture  process  is  relatively  fast,  allowing  graphs  of  several  thousand  nodes  to  be 
captured  in  a  few  weeks  or  less.  The  editor  also  provides  some  run-time  syntax 
checking,  catching  many  errors  during  the  edit  process. 

The  output  of  the  graph  editor  is  passed  to  the  graph  source  generator,  which  creates  an 
intermediate  source  language  that  is  more  amenable  to  automatic  document  generation  and 
syntactic  debugging. 

The  graph  parser  accepts  the  intermediate  source  code  and  performs  extensive  syntactic 
and  semantic  error  checking.  It  ensures  that  all  data  typing,  and  queue  initialization 
is  defined  and  compatible.  The  output  of  the  graph  parser  can  be  passed  to  any  of  a 
number  of  compilers. 

The  graph  tool  set  currently  supports  compilers  for  a  system  level  simulator,  a  graph 
simulator,  and  the  target  machine  hardware.  The  system  level  t/lmulator  allows  the  user 
execute  a  graph,  without  explicitly  evaluating  the  nodes.  Node  execution  is  treated  as  a 
black  box  with  a  specified  execution  time.  The  graph  simulator  is  used  to  debug  the 
application  function.  It  executes  the  underlying  function  of  each  node,  though  not 
necessary  in  real-time  nor  concurrently. 

Studies  have  been  performed  to  evaluate  the  relative  improvement  provided  by  functional 
graph  programming  over  conventional  languages.  These  studies  was  performed  using  real- 
world  applications,  complete  with  I/O  and  control.  The  result,  show  that  on  average,  the 
ECOS  graph  language  provided  a  five-fold  decrease  in  the  code  and  teat  phases  over 
traditional  high-level  languages.  Although  there  are  no  studies  to  evaluate  improvements 
in  the  support  and  maintenance  phase,  the  ease  with  which  a  person  can  grasp  the 
underlying  process  of  a  complex  graph  does  suggest  that  a  significant  savings  may  occur. 

V«  The  Kun-Tlme  Executive  -  Making  a  Kaohine  Tranaparamt 

The  EHSP  data-flow  executive  software  provides  a  transparent  interface  between  the 
application  program  and  the  machine  hardware.  This  executive  la  based  on  s  eoarae-graln, 
data  flow  paradigm  that  schedules  nodes  based  on  the  availability  of  their  data  inputs. 
The  executive  provides  three  basic  functions:  queue  management,  node  scheduling  and 
aaalgnmant,  and  node  execution.  Figure  3  show  tha  relationship  and  Information  passed 
between  these  functions. 
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The  queue  manageaent  function  creates,  aonitors,  and  deletes  queues.  Queues  are 
aalntained  as  dynaalo  FIFO  structures,  with  associated  attributes  such  threshold  and 
capacity.  The  threshold  la  a  user  defined  value  or  expression  that  specifies  the  ainlaua 
number  of  iteaa  needed  in  the  queue  for  its  sink  node  to  execute.  Vhen  the  nuaber  of 
eleaents  in  the  queue  aeets  or  exceeds  threshold,  a  threshold  aessage  is  sent  to  the 
scheduling  function.  No  further  threshold  aessages  are  peraltted  from  that  queue  until 
its  node  completes  execution.  When  one  or  more  queues  are  Input  to  a  node,  each  queue 
aust  exceed  threshold  before  a  node  can  be  executed.  The  queue  capacity  is  priaarily  a 
warning  parameter  that  the  queue  will  soon  reach  an  over-capacity  status  and  overload 
aanageaent  should  be  invoked. 

The  scheduling  and  assignment  function  deteralnes  when  all  of  the  inputs  to  a  node  are 
available,  and  assigns  the  node  to  an  available  processor.  It  performs  this  function 
through  the  use  of  two  tables.  The  queue-to-node  table  is  basically  s  connectivity  map 
that  specify  the  queue's  produce  and  consume  node  ports.  Each  queue  connects  at  most  two 
nodes  -  one  that  produces  data  into  the  queue,  and  one  that  consumes  data  from  the 
queue.  The  queue«to-node  table  provides  a  pointer  to  a  node  status  table  that  maintains 
a  list  of  all  inputs  for  each  node  and  their  threshold  status.  When  all  the  necessary 
inputs  are  available  for  a  given  node.  It  is  assigned  firing  status.  It  is  priority 
queued,  being  assigned  to  the  first  available  processor  that  has  the  resources  to 
execute  the  node.  This  assignment  is  completed  by  sending  the  node's  instruction  stream 
to  the  node  execution  function. 

The  node  execution  function  executes  node  instruction  streams.  This  instruction  stream 
specifies  where  to  obtain  the  input  data,  rules  for  computing  memory  storage,  and  the 
functions  to  be  performed  on  the  inputs.  It  also  specifies  where  to  output  the  data  and 
what  Input  data  la  to  be  consumed  (destroyed).  When  this  is  completed  for  a  given 
instruction  stream,  a  completion  message  Is  sent  to  the  scheduling  function.  This 
message  Informs  the  scheduler  that  the  processor  has  completed  the  node  execution,  and 
la  free  to  execute  another  task.  It  also  permits  that  node  to  be  scheduled  again,  once 
its  inputs  are  available. 

In  a  typical  application  this  process  is  carried  on  concurrently  for  thousands  of  nodes 
and  queues.  The  use  of  dynamic  assignment  not  only  simplifies  load  balancing  and 
parallel  processing,  but  it  also  provides  an  effective  means  of  fault  recovery.  If  a 
proceaaor  fails  during  execution,  its  nodes  are  simply  reassigned  to  another  processor, 
as  the  Inputs  are  not  consumed  until  the  node  has  successfully  executed. 

V.  THE  EN3P  Machine  -  Scaling  from  HOPS  to  COPS 

The  EHSP  architecture  Is  an  open,  modular  architecture  that  Is  capable  of  supporting  a 
wide  variety  of  configurations  and  platforms.  This  versatility  is  achieved,  in  part,  by 
a  set  of  system  building  blocks  called  functional  elements.  Each  element  uses  the  same 
protocols  and  Internal  data/control  Interfaces.  The  basic  EMSP  architecture  consists  of 
four  types  of  functional  elements:  a  scheduler,  a  command  processor,  global  memories, 
and  processing  alementa  (See  Figure  4).  These  functional  elements  are  combined  into  a 
system  by  separate  data  and  control  transfer  networks. 

The  command  processor  supports  graph  management,  system  control,  performance  monitoring, 
and  fault  management.  It  executes  the  command  program  part  of  the  application  program. 
The  scheduler  maintains  the  execution  status  for  all  the  nodes  in  a  graph,  and  assigns 
executable  nodes  to  available  processing  elements.  It  maintains  the  queue-to-node 
table,  the  node  status  table,  and  the  available  processor  queue.  Both  the  scheduler  and 
command  processor  may  be  configured  as  a  doubly  redundant  function  element  for  Improved 
fault  tolerance. 

The  global  memories  are  intelligent  repoaltoriea  for  the  storage  and  management  of 
queues,  node  instruction  streams,  and  auxiliary  graph  entitles.  They  dynamically 
allocate  and  de-allocate  memory  for  queue.  They  send  queue  threshold  and  capacity 
messages  to  the  scheduler,  and  instruction  streams  and  data  to  the  processing  elements. 
Each  global  memory  conalsta  of  a  control  processor  module  and  one  or  more  bulk  memory 
module. 

The  processing  elements  decode  node  instruction  streams  and  perform  the  primitive 
functlon(s)  specified.  The  EMSP  architecture  supports  a  variety  of  processing  elements 
such  as  a  floating-point  signal  processor,  1/0  processors,  special  signal-conditioning 
preprocessors,  and  data  proceasora.  Processing  elements  typically  consist  of  a  control 
processor  that  decodes  the  instruction  stream  and  manages  Internal  memory.  Separate, 
special  purpose  prooesaors  execute  the  primitive  functions  as  directed  by  the  control 
processor.  This  approach  permits  simultaneous  setup,  execution,  and  breakdown  to  occur 
within  a  processing  element. 

The  functional  elements  are  interconnected  by  aeperate  data,  control,  and  built-in-test 
networks.  The  data  transfer  network  consists  of  a  non-blocking,  asynchronous,  buffered 
switch  network  that  permits  simultaneous  transfers  between  functional  elements.  The 
control  meaaagea  and  BIT  date  are  transferred  over  separate  busses. 

VIX.  ConolusiOB#  -  The  Proof  is  in  the  Deployment 

Over  500  staff-years  of  development  have  made  the  EHSP  architecture  into  a  auoeeasful 
and  mature  product.  It  la  the  Navy's  standard  signal  processor,  the  AN/UYS-2.  It  is  a 
fully  mil-qualified,  production  system  with  extensive  documentation  and  support 


37-5 


software.  Its  ECOS  language  has  been  demonstrated  to  provide  a  five-fold  reduction  in 
software  costs  over  traditional  high-order  language  systems.  It  is  currently  being  used 
to  capture  complex  real-world  applications  consisting  of  thousands  of  queues  and  nodes. 
The  architecture  provides  between  40S  and  90S  execution  efficiency  across  all  processing 
elements  for  a  broad  range  of  applications.  It  is  targeted  for  numerous  military 
programs.  A  second  generation  architecture  is  scheduled  for  production  in  two  yearsi  and 
will  provide  a  five-fold  Improvement  In  throughput  density,  with  enhanced  data 
processing  capabilities.  A  third  generation  architecture  (MGP)  Is  currently  in  the 
research  and  development  phase,  and  promises  another  factor  of  five  increase  in 
throughput  density.  It  will  also  provide  additional  data  and  decision  processing 
capabilities.  The  HGP  architecture  will  provide  over  four  billion,  32-bit  floating 
point  operations  per  seconds  (signal  processing)  and  100  million  instructions  per  second 
(data  processing)  in  a  1.5  cubic  foot  enclosure. 

In  conclusion,  this  architecture  has  achieved  all  its  initial  goals  through  the  marriage 
of  a  functional  programming  language,  a  data-flow  executive,  and  a  modular, 
heterogeneous  multiprocessor. 
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DISCUSSION 

G.PiriS(  Fr 

Aren't  the  two  last  papers  a  solution  to  the  quesbon  “Can  Ada  fly  missiles"?  We  must  have  standardized  Ada,  a 
methodology  and  communicabon  tools  if  we  hope  to  realize  software  reusability.  What  is  your  opinion? 

Author’s  Reply 

I  agree!  The  purpose  of  the  graph  langriage  and  tools  presented  here  is  to  supplement  rather  than  replace  Ada.  The 
graph  language  is  a  very  effecbve  program  desi^  language  (POL).  It  also  simplifies  coding  and  tesbng  by  automabcally 
generating  the  interface  or  "public"  portion  of  an  ADA  package. 


r 


M,Sioll,Fr 

When  you  use  this  tool  to  update  a  system,  how  do  you  generate  the  modiflcabon  and  how  do  you  manage  the 
configuration? 

Author’s  Rqily 

Updates  and  configuration  management  for  graphs  are  performed  in  much  the  same  manner  as  conventional  programs. 
One  can  add,  delete  and/or  modify  graphs,  sub^phs  or  nodes.  In  many  ways  the  update  process  is  simpler  because  the 
application  process  is  easier  to  grasp  in  a  picture  (graph)  form  vs.  acmal  code.  Also,  graphs  have  good  locality  of  effect. 
That  is,  changes  tend  to  impact  only  very  local  regions  in  the  graph.  Graphs  and  subgraphs  are  stored  as  files  that  can  be 
linked  and  edited  in  a  manner  similar  to  other  software  files. 


P.Tillinan,  UK 

Will  graphical  languages  such  as  yours  make  Ada  obsolete  in  the  medium  term? 

Author’s  Reply 

The  graph  language  presented  in  this  talk  supplements,  rather  than  replaces,  languages  such  as  Ada.  It  is  important  to 
remember  that  the  primitive  kernels  of  nodes,  the  I/O  procedures  and  the  command  program(s)  are  programmed  in  a 
HOL  (Ada  or  SPGN).  In  practice,  approximately  50+%  of  the  traditional  HOL  code  is  captured  using  the  graph 
language.  In  many  ways,  tlus  corresponds  to  the  relationship  between  HOLs  and  assembly  languages. 


W-Mansell,  Ge 

The  effort  saved  using  the  GPL  method  compared  to  HOL  seems  astonishing.  Can  you  comment  on  how  this  reduction 
is  achieved? 

Author’s  Reply 

There  is  no  single  contribution  that  accounts  for  this  dramatic  improvement;  but  rather  it  is  the  re.sult  of  many 
attributes.  These  include: 

( 1 )  Pictures  (graphs)  are  easier  to  produce  and  comprehend 

(2)  Data  flow  graphs  are  side-effect  free. 

(3)  Data  flow  graphs  naturally  capture  parallelism  (@  coarse-grain  level). 

(4)  Graph  provides  good  locality  of  effect. 

(5)  They  permit  higher  levels  of  abstraction. 

(6)  The  graph  compiler  automatically  generates  correct  interface  code  (the  public  portion  of  an  Ada  package/ 
procedure). 

It  should  be  noted  that  application  primitives,  command  programs  and  I/O  packages  must  still  be  written  in  Ada.  Thus, 
the  five-fold  improvement  (of  the  graph  language)  over  HOLs  translates  into  about  a  SO  to  60%  improvement  in  overall 
lifecvcle  costs. 
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Summary : 

The  use  of  Expert  System  techniques  for  radar  idenliTicaiion  in  counter-measure  systems  has  been  widely 
discussed  in  die  literaoite.  The  main  advantages  of  such  a  system  are  that  it  is  easily  adaptable  to  the  ever 
changing  (^erational  field  and  that  it  can  identify  modem  radars  with  their  increasingly  complex  signals. 
These  systems  are  however  very  demanding  on  computing  ressources  and  their  adaptation  to  on-board,  real¬ 
time  processing  is  not  straightforward.  In  this  pa^.  the  application  under  consideration  is  first  briefly 
described.  The  constraints  that  arise  out  of  its  real  time  operation  ate  then  detailed  along  with  how  each  one 
can  be  eliminated.  The  applicadon  of  these  concepts  to  a  teal  time  radar  identification  function  is  then 
described.  Finally,  future  objectives  in  the  integration  of  Artificial  Intelligence  techniques  for  on-board 
processing  are  discussed. 


1.  Introduction 

The  use  of  Expert  System  techniques  for  radar  identification  in  counter-measnte  systems  has  been  widely 
discussed  in  die  literature.  The  main  advantages  of  such  a  system  are  that  it  is  easily  adaptable  to  the  ever 
changing  operational  Held  and  that  it  can  identify  modem  rad^  with  their  increasingly  complex  signals. 

One  possible  use  for  a  radar  identifier  is  onboard  an  aircraft  to  instantly  give  the  pilot  valuable  information 
about  the  immediate  threat  situation.  However,  Expert  Systems  are  usu^y  very  demanding  on  computer 
ressources  and,  the  change  from  a  large  compuuu’  laboratory  environment  to  a  small  size  computer  in  a  teal 
time  environment  is  accompanied  by  obvious  problems.  Both  the  application  structure  and  the  computer 
tools  must  be  reviewed  in  Older  to  satisfy  the  teal  time  operational  constraints. 

In  this  paper,  the  application  under  consideration  is  first  briefly  described.  The  limitations  that  arise  out  of  its 
real  time  operation  are  then  detailed  along  with  how  each  of  these  limitations  can  be  overcome.  The 
application  of  these  concepts  to  a  real  time  radar  identification  function  is  then  described.  Finally,  future 
cbjectives  in  the  inlq^iation  of  Artificial  Intelligence  techniques  for  on-board  processing  are  stated. 

2.  Coimtermcasurcs  Environment 

In  modem  defense  techniques,  an  aircraft  mission  must  be  backed  up  by  appropriate  electronic  procedures. 
Success  very  much  depends  on  knowledge  of  the  enemy’s  electronic  oeiez  of  battle  (EOB).  For  these 
procedures  to  be  successful,  the  first  step  to  be  accom|dished  is  to  identify  the  th.eats  and  then  to  decide  for  an 
qn>toptiate  action  to  be  undertaken. 

The  threats  are  identified  through  their  associated  radars  by  processing  the  electro-magnetic  information 
gathered  by  an  aiibrmie  Electronic  Warfare  sensor.  The  sensor  measures  the  characteristics  of  the  emitted 
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pulteg  and  cttriei  out  prelimiiiary  sorting  to  bring  together  pulses  concsponding  to  the  same  ladar  signal.  The 
identilicatkiB  is  then  peifonned  by  comparing  the  incoming  signal  with  a  predefined  lUmy  of  signatures. 
Figure  1  gives  the  overall  structure  of  an  Electronic  Warime  System. 


3.  The  Identification  Function 
3.1.  Identincation  Problems 


However,  identification  gets  harder  as  the  complexity  of  modem  emissions  increases.  Moreover,  in  case  of 
conflict,  the  threat  characteristics  ate  very  likely  to  change  as  new  or  undiscovered  radar  operating  modes  are 
used,  requiring  a  system  which  is  easily  adapuble.  Conventional  identification  algorithms  are  often 
unsatisfactory  and  difficult  to  adapt  to  a  chmging  operational  field.  As  human  experts  exist  who  are  able  to 
carry  out  identification,  expert  system  a{q;)roaches  to  the  problem  have  been  taken  and  have  been  discussed  by 
various  authors  in  [1,2^3]. 

The  first  phase  of  our  project  was  to  design  a  prototype  to  demonsuate  the  validity  of  the  approach  using 
powerful  Artificial  Intelligence  techniques  without  any  limitations  on  computing  power,  response  time  or 
memory  space  requirement  The  resulting  prototype  is  briefly  described  in  the  next  section,  more  details  are 
available  in  [1]. 

As  the  first  phase  was  compleusd  successfully,  the  next  step  was  to  take  into  account  the  teal  time  limitations 
to  evaluate  the  possibility  of  integrating  the  system  directly  into  a  fighter  with  very  limited  computing  power. 

3.2.  Non  Real-time  Identification 

The  signab  to  be  identified  ate  gathered  during  flight  by  an  ESM  sensor.  However,  identification  takes  place 
only  when  the  flight  is  finished,  in  a  conventional  computer  center,  with  a  large  amount  of  computing 
tessources.  The  principles  of  the  identification  process  were  directly  derived  from  interviews  and  observation  of 
a  knowlegeabie  radar  identification  technician  (i.e.  the  domain  expert).  The  main  development  goal  was  to 
rqiroduce  as  closely  as  possible  his  reasoning  process. 

3.2.1.  Principles 

Two  aqtects  of  the  human  expert  are  taken  into  consideration.  First,  WHAT  ate  the  sources  of  knowledge  that 
ate  tise^  and  second,  HOW  is  all  this  knowledge  used  to  perform  the  identification  ?. 

The  sources  of  knowledge  used  by  the  expert  are  of  three  kinds.  First,  the  knowledge  of  existing  radars  and 
there  characteristics,whi^  is  stored  in  a  conventional  data  base  management  system.  Second,  the  existence  of 
special  algorithms  used  by  the  expert  to  find  out  special  features  of  the  si{^.  Last,  the  expert's  specific 
Imowledge  relative  to  the  sensor  limitations,  to  the  radar  operational  functions  and  to  the  geographical  or 
poUtical  operatranal  envitoamenL 

Tlie  identification  process  is  divided  into  four  main  steps.  The  first  is  a  qudiiaitve  analysis  of  the  incoming 
signaL  It  ensures  detection  of  defective  sensm  working  and  possible  corrective  action  using  special 
mgatithms.  The  second  is  data  base  selection  in  which  a  few  likely  candidates  ate  extracted  fiom  the  Iflrr^  for 
identification.  In  the  third  step,  each  candidate  is  thoroughly  analyzed  to  find  the  one  that  matches  the  signal 


39-3 


best.  A  founh  step  may  be  activated  if  the  above  fail  to  give  a  satisactory  answer.  It  consists  in 
hypothesizing  about  operating  conditions  of  the  sensor,  ndar  or  about  any  known  phenomenon  in  the 
eavtnnmenL  Hguie  2  gives  the  overall  structure  of  the  non  realtime  expert  identifier. 


SIGNAL  ^ 
J  F,  PW,  PBF,  DOA,  .») 


Fitturc  2  :  Expert  Identifier  Structure 


3.2.2.  TriaU 


The  use  of  real  data  ensures  that  the  trials  are  not  biased  by  an  incomplete  simulation  of  all  the  operational 
problems.  Various  prototypes  have  been  implemented  on  various  tools.  The  best  results  were  obtained 
using  the  expert  sysim  compiler  SFOCK  (described  later  and  in  [4,6]).  An  identification  can  be  performed  in 
an  avera^  time  of  less  than  one  second  on  a  microvax  II.  The  possibility  of  integrating  the  system  in  a  real 
tune  environment  can  therefore  be  considerod. 

4.  Real  Time  Requirements 
4.1.  Constraints 

All  the  requirements  inherent  in  an  aircraft  operation  must  be  taken  into  consideration.  They  can  be  placed  in 
three  different  categories  which  are : 

-  Computiiig  resources  constraints 

-  Software  Ini^iato  constraints 

-  Application  Design  constraints 


Each  of  these  is  discussed  in  the  following  sections. 
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4.1.1.  Comp«ti0|  RcMMircci  Coutratels 

Conpuier  Resources  on  a  fighter  are  limited  by  the  size  and  weight  availaUe  (a  few  printed  circuit  boards 
only),  and  by  the  enviroamentai  constraints.  In  most  cases  no  disk  storage  is  available  and  therefore  no 
vhUitfmeiiKiry  system  can  be  implemented.  Memory  and  CPU  usage  must  dierefote  be  limited  (taastically. 

Fiirthennote,  an  aiiborae  system  must  be  in  operation  continuously  during  the  mission,  and  procedures  such 
as  memory  garbage  collection  (used  in  most  of  the  Artificial  Intelligence  systems  today  to  recover  the  memory 
no  longer  used  by  the  program)  are  therefore  not  accq>iable. 

4.1.2.  Software  Integration  Constraints 

If  the  expert  system  must  be  added  to  existing  equipment,  additional  constraints  appear.  It  must  then  be 
integrated  to  an  existing  real  time  operating  system  and  to  conventional  software  and  hardware  for  data 
communication  between  the  different  {xocesses.  The  use  of  a  common  programming  language  is  therefoie 
recommended  for  all  parts  of  the  system  (C,  A0A,  LTR3, ...) 

4.1.3.  Application  Function  Constraints 

Some  operational  constraints  of  the  identification  function  were  not  taken  into  account.  In  a  fighter 
environment,  the  system  must  give  a  usable  result  in  a  given  time  and  must  be  able  to  process  constantly 
evolving  data. 

4.2.  Solutions 

To  overcome  all  these  limitations,  various  aspects  requiring  major  changes  are  involved.  Waiting  for  more 
powerful  computers  to  appear  is  not  the  complete  solution  to  the  problem.  A  high  performance  toot  must  be 
used  and  the  applicadoa  must  be  deeply  restructured. 

4.2.1  A  High  Performance  Expert  System  Shell 

Pan  of  the  solution  is  to  use  a  specialized  expert  system  generamr  to  achieve  a  trade-off  between  high-level 
functions  and  speed.  An  example  of  such  a  system  is  SPOCK.  A  detailed  description  of  SPOCK  is  given  in 
[4,fi41]i  Its  main  functions  and  conoibutions  to  real-time  operation  are  the  followings: 

SPOCK  is  an  expert  system  generator  that  produces  a  conventional  program  in  a  given  language  (Lisp,  C  or 
ADA).  The  program  can  then  be  compiled  for  fast  execution  on  the  target  machine.  No  extra  time  is  thus 
spent  by  the  language  interpr^r  as  in  a  lot  of  expert  system  shells.  This  feauire  also  facilitates  the 
inlegratian  of  the  expert  system  in  a  real  time  environment  and  to  conventional  software  and  hardware. 

The  heart  of  SPOCK  also  manages  its  own  memory  resources,  it  does  not  therefore  need  to  be  stopped  for 
memory  recovery  (garbage  collection)  and  so  is  available  for  continuous  operation. 

It  includes  some  functions  relating  to  the  faculty  of  reasoning  in  the  lime  domain,  enabling  it  to  consider  the 
constant  updating  of  the  information.  Mechanism  is  also  provided  for  asynchronous  input  of  data. 

SPOCK  is  being  developped  by  the  Research  Central  Laboratory  of  THOMSON-CSF  in  three  versions  that 
corespond  to  difierent  function  level  in  mder  to  integrate  the  major  artificial  intelligence  paradigms  such  as 
fotwardAmckward  chaining,  first  order  predicate  calculus,  objects  manipulation,  non-monolonic  reasoning  and 
multiide  hypothesis  maniptilation. 

4.2.2  Need  for  Restrncturing  the  Application 

The  tgiplicatian  itself  must  be  redesigned  to  take  into  account  some  of  the  real-time  limitations. 

To  be  aUe  to  provide  a  usable  result  in  a  pven  time,  the  system  should  have  different  lines  of  reasoning 
euMing  it  to  process  the  same  data  with  various  computing  costs  and  qualities  so  that  the  system  can  choose 
the  moat  appropriate  one  dqiending  on  the  computing  time  available.  This  idea  was  first  mentioned  in  [S],  it 
can  be  achieved  by  structuring  the  knowledge  biM  at  levels  which  are  difiereot  and  diat  are  activated  according 
to  availaUe  time.  Examples  are  given  in  the  next  section. 


39-5 


The  knowledge  base  must  also  be  able  lo  process  constantly  evolving  data.  That  is,  it  must  be  able  to  cancel 
part  of  the  reasoning  when  some  of  the  ^ta  changes  and  to  lake  into  account  the  tqterational  meaning  of 
successive  signal  stales. 

5.  Real-time  Radar  Identification 

To  prototype  the  real  time  system,  a  simulation  of  the  real  lime  data  flow  is  done  on  the  basis  of  real  data 
gathered  during  flights  with  ESM  sensors.  In  the  next  section,  a  description  of  the  simulation  is  given.  The 
problem  of  hierarchizing  the  knowledge  base  is  then  discussed. 

5.1.  Simulation  Structure 

The  overall  structure  of  the  simulation  is  given  in  figure  3. 

The  signal  constiuition  element  carries  out  preprocessing  of  the  measured  data.  This  consists  in  creating  and 
updating  signals  in  the  common  workspace.  Techniques  used  are  derived  from  various  clustering  techniques. 


Flgure3^SlmiiIationStriJCti^ 


When  a  signal  is  considered  sufficently  good,  an  identification  request  is  sent  to  the  identifier  on  an 
asynchronous  basis.  Furthermore,  when  a  signal  undergoes  significant  modific.'itions,  a  re-identification 
request  is  sent  to  the  identifier. 

5,2.  Multiple  Levels 

The  knowledge  base  of  the  identification  process  is  organized  in  several  levels.  This  enables  Uisks  to  be 
performed  according  to  priority.  That  is,  the  expert  system  first  processes  ail  level  one  requests.  When  no 
more  inferences  are  possible  at  this  level,  it  switches  to  the  next  level,  until  a  lower  level  task  is  initiated. 
Switching  from  one  level  to  the  other,  can  be  done  asynchronously  between  the  firing  of  any  two  rules. 

A  description  of  typical  processing  at  each  level  follows: 

Level  1 :  Low  level  or  high  priority  processing 

-  systematic  pre-identification  of  idl  identification  requests  from  the  signal  constitution  element 

-  high  priori^  identifications  determined  in  the  {ve-identification  phase. 

Level  1 :  Medium  complexity  processing 

-  Analysis  of  complex  quality  criterion  that  requites  more  processing  power. 

•  Confirmation  of  pre-identifications. 
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Level  3 :  Higb  compleuty  processiiig 

-  Eieculioii  of  comptodwiiungelgoriihiM  when  tome  criteria  value  lequiieste. 

-  geaetalion  of  complex  hypoth^ 

Different  lines  of  reasoning  for  (he  same  problem  may  be  implemented  at  different  levels.  In  this  case  the 
idenliftattion  achieved  at  a  given  level  can  be  refined  by  the  reailis  of  a  higher  level. 

Initiation  of  a  task  at  a  given  level  is  either  by  a  request  from  the  signal  constitution  module  or  by  any  rule  in 
the  knowledge  base.  The  processing  of  a  signal  can  therefore  dynainically  move  fiom  one  level  lo  another. 

5.3.  Evolving  Data 

Constantly  evoluting  data  can  introduce  problems  in  (he  identification  process.  A  modification  of  the  signal 
may  contradict  previous  inferences.  The  system  must  therefore  be  able  to  cancel  these  inferences  and  start  a 
new  identification.  An  initiated  task  at  a  high  level  not  yet  executed  may  also  be  cancelled  when  additional 
information  arrives.  , 

The  use  of  non-monotonic  logic  can  ease  the  implementation  of  such  a  feature.  For  example,  a  rule  might 
say: 

IF 

a  quality  criterion  number  1  is  lower  than  a  given  threshold 
THEN 

several  signals  are  mixed 
AND  initiate  special  processing  at  level  3 

When  this  rule  fires,  the  special  processing  is  not  executed  immediately;  subsequent  information  can  change 
the  value  of  the  criterion  and  therefore  the  special  processing  is  deactivate  automiatically. 

5.4.  Trtote 

The  prototype  of  the  system  is  written  on  a  microvax  II  computer  using  SPOCK  as  an  expert  system 
generator  in  LeLisp  language,  conventkmal  algorithms  are  coded  in  PASCAL. 

Particuliar  attention  will  be  paid  to  computer  resources  used  by  the  system.  As  trials  are  carried  out  with  real 
data  rqiresentative  of  a  very  dense  radar  environment,  the  results  will  give  a  good  insight  into  the  required  epu 
performance  and  storage.  It  will  then  be  possible  to  precisely  dimension  the  computer  dwt  should  be  put  into 
the  aircraft  for  a  given  identification  performance  obj^ve. 

6.  Conclusion 

The  main  constraints  associated  to  real  time  integration  of  expert  system  techniques- has  been  stated.  To  use 
more  powerful  computers  is  not  enough,  performance  can  and  must  also  be  gained  on  the  software  side  of  the 
probim  first  by  using  a  high  performance  expert  system  generator  as  STOCK  and  second  by  thoroughly 
restructuring  the  applicalion  itself  to  adapt  it  to  the  required  real  time  environment  An  example  has  been 
given  of  an  expert  system  for  real-time  radar  identification  derived  from  a  non  real-time  eiqtert  system.  The 
combination  of  these  techniques  will  shortly  make  it  possible  to  imegraie  the  expert  system  on  an  operational 
equipment  without  having  to  rewrite  the  entire  ^tpikation  using  convendonal  programing  techniques.  The 
high  degree  of  flexibility  of  these  techniques  will  therefore  mbie  more  poweifol  systems  to  be  installed 
onboard  aircrafts. 

The  long  term  objective  is  to  further  facilitate  the  use  of  these  techniques  by  int^nting  directly  to  an  ADA 
programmiag  environment,  an  object  manipulation  layer  and  a  production  rule  Iqrer. 
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DISCUSSION 


RMarmelstein,  US 

My  concern  is  that  the  SPOCK  system  may  have  trouble  managing  memory  resources  on  an  Ada  based  expert  system. 
In  many  compilers,  unchecked  deallocation  is  implemented  with  varying  degrees  of  effectiveness.  This  may  result  in 
ultimately  running  out  of  memory. 

Author’s  Reply 

Memory  management  in  SPOCK  does  not  rely  on  the  Ada  deallocation  system.  The  inference  engine  uses  Ada  data 
structures  of  fixed  sire  and  does  not  need  to  be  extended  unless  the  memory  is  full. 
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RESUME  :  Les  systimes  experts  embarquEs  dolvent  prendre  en  conpte  des  contraintes  teeps  rEel  sEvEres,  qu1, 
assoclEes  aux  contraintes  d'envlronneaient  de  1a  machine  d'exEcutlon,  obllgent  i  rechercher  des  solutions 
nouvelles.  La  procEdurallsatlon  obtenue  par  compilation  de  Valgorlthmie  de  RETE  vers  des  langages  cibles 
symbollques,  procEduraux  ou  orient^  temps  r^1  apporte  une  solution  aux  principaux  problEmes  des  applica¬ 
tions  embarquEes  ;  Besolns  de  vltesse,  contrEle  de  la  mEmoIre,  marlage  des  parties  symbollques  et  des  par¬ 
ties  classiques  des  applications.  Cette  approche  est  soutenue  par  la  famine  des  outlls  SPOCK  (-LISP,  -C, 
-LTR3,  -ADA)  developpEe  par  1e  Laboratolre  Central  de  Recherche  de  Thomson-Csf,  qui  offre  des  amEllora- 
tlons  significatives  par  rapport  aux  prodults  actuellement  disponibles.  Une  des  applications  de  SPOCK  dans 
Thomson-Csf  est  un  systEme  d'alde  aux  missions  d'hEllcoptEres  prenant  en  compte  1es  menaces  et  le  relief 
grice  au  couplage  E  une  base  de  donnEes  cartographlque  embarquable. 

ABSTRACT  :  The  avionic  real  time  expert  system  designer  Mill  non  receive  help  from  a  set  of  software  tools 
developed  In  the  Centra!  Research  Laboratory  of  Thomson-Csf.  Through  RETE  algorithm  compilation  targeting 
conventlonnal  (C)  or  real-time  (ADA)  languages,  the  SPOCK  tools  family  offers  an  Improvement  close  to  one 
order  of  magnitude  In  performance,  rated  to  currently  available  tools.  SPOCK  Is  used  In  several)  military 
divisions  of  Thomson-Csf  ;  this  paper  describes  SPOCK  and  Its  application  to  an  AI  based  mission  help  for 
helicopters. 


1  CONTRAINTES  DES  SYSTEMES  EXPERTS  TEMPS  REEL  EMBARQUES 

Sexploitation  opEratlonnelle  d'un  systeme  expert  dans  les  applications  mllltalres  embarquEes  dolt  prendre 
en  coepte  1es  spEcIfleltEs  de  ces  applications,  et  les  machines  d'exEcutlon  s'adapter  aux  conditions 
d'envlronneaient  sEvEres  rencontrEes. 

Pour  la  partle  systEme  expert,  on  rencontrera  les  besolns  sulvants  : 

-  Analyse  de  situation  et  prise  de  dEcIslon  en  teagis  rEel  au  sens  de  1'avlonnlque  «0.I  S), 

-  Prise  en  compte  au  niveau  ralsonnement  des  aspects  tengiorels  et  spatlaux, 

-  CapacItE  i  tralter  des  Informations  tronquEes  ou  IncomplEtes, 

-  Cohabitation/fusion  avec  des  applications  ou  des  traltements  conventlonnels 
(algorlthmie/calculs/gestlon  d'entrEes-sortles...), 


Pour  la  auchlne  embarquable,  1es  contraintes  sent  d'offrir  sous  le  plus  falble  volume  possible,  avec  la 
consoamiatfon  la  plus  i^dulte  et  dans  des  amblances  de  tempEratures  et  de  vibrations  exigeantes  : 

-  Des  ressources  mEmolres  Etendues, 

-  Des  capacItEs  de  traltement  trEs  ElevEes  en  coaRaralson  des  besolns  des  traltements  dasslques. 


2  SOLUTIONS  ENVISAGEABLES 

Pour  rEpondre  aux  besolns  de  traltement  on  peut  envisager  trols  approches  : 

2.1  FORCE  BRUTE 

La  machine  d'exEcutlon  prEsente  la  plus  grande  puissance  de  calcul  possible  (quelques  MIPS,  voire  plus) 
en  vertu  de  1 'Equivalence  entre  une  InfErence  et  quelques  dizalnes  d' Instructions  classiques.  Le  systEme 
expert  lul-mEme  est  Ecrit  dans  un  langage  conventlonnel,  Pascal  ou  C,  Eventuellemtnt  un  langage  teaqis 
rEe1,  LTR3  ou  ADA. 

AVANTAGES  ; 

-  Pas  de  mEcanIsme  coflteux  de  rEcupEratlon  mEmolrc  i  rEallser, 

-  IntEgratfon  alsEe  avec  le  rcste  de  1 'application,  1u1  mEme  Ecrit  dans  un  langage  de  ce  type. 


INCONVENIENTS  : 

-  EnvIronnoMnt  de  diveloppcaent  sjiabollquc  tris  piuvre  pour  les  lanpiges  cltds, 

-  (Hfficuttds  ou  lourdeurs  pour  rioHser  cerUfnes  parties  du  systjae  expert, 

-  Doutes  sur  let  capacltds  de  cette  approche  1  rdallser  des  applications  ‘syaibol 1 ques’  trds  per- 
foraantes. 

Exeaq;i1e  de  riallsatton  ;  Systtae  expert  HEXSCON  du  SRI. 

2.2  SVMBOLIQUE  PURE 

2.2.1  Sur  (tachlne  classique 

C'est  une  approche  baste  sur  la  ph11os<H>h1e  aachlne  prtctdente,  avec  1'eaq>1o1  d'un  lanqage  de  type  sytd>o- 
llque  (COMMON-LISP,  PR0L06,  ...)  coaplli  pour  de  aellleures  perforaunces. 

AVANTAGES  : 

-  L'environneaent  de  diveloppeaent  est  trds  riche. 

-  Les  perfonaances  peuvent  ttre  trds  bonnes  sous  certalnes  conditions  (pas  de  rtcuperatlon  mf- 
anlre  activte). 

INCONVENIENTS  : 

-  Ces  uchlnes  n'ayant  pas  de  aCcanlsaes  aattrlels  de  rtcupdratlon  d'espace  utaiolre  dolvent 
stopper  tout  tralteaant  pendant  des  Intervenes  variables  (dtpendant  de  la  ta111e  nitaioire  1ns- 
talite  et  du  probliae  traitt)  et  s'avdrent  peu  utlllsables  pour  des  applications  tenps  rtel. 

-  Les  Interfaces  logiclelles  avec  les  langages  classiques  sont  nl  comodes. 

EXEMPLES  ;  Stations  de  dtveloppcBKnt  SUN  (type3-XXX),  TEKTRONIX.HP. . . 

2.2.2  Machine  i  architecture  dtdite 

Ces  Mchlnes  sont  construltes  sur  des  architectures  sptc1a11stes  (association  d'ltlquettes  aux 
donates,  rtcuptratlon  ataiolre  ctbite,  atcanisaws  adaptts  aux  particularitts  du  langage,  ...1  pour  les  lan¬ 
gages  sxabollques. 

A  condition  de  les  dtbarrasser  de  leur  environneaent  de  dtveloppeaent  pour  en  faire  des  Machines 
d'extcutlon,  elles  peuvent  prttendre  au  crtneau  lA  eabarqute. 

AVANTAGES  : 

-  L'identitt  aachlne  de  dtveloppeaent/aachine  d'extcutlon  assure  1a  rtpHabllltt  des  perfonnan- 
ces  du  laboratoire  vers  1'appllcatlon. 

INCONVENIENTS  : 

-  Les  ataes  qu'au  paragraphe.  pour  1e  logiclel 

-  La  ntcessitt  de  rtduire  1 'encoabreaent  de  la  aachlne  par  des  actions  d'inttgratlon  pousste. 
EXEMPLES  : 

-  Coapact  Lisp  Machine  de  TEXAS  avec  VLSI  LISP  (MEGACHIP). 

-  Machines  STMBOLICS  avec  1e  nouveau  VLSI  CIVORY*). 

Pour  ces  prodults,  Vaccts  sans  restrictions  i  des  versions  allltalres  n'est  garantle  par  aucun  des  deux 
fabri cants. 

2.3  PROCEDURALISATION 

Cette  approche  est  dfveloppte  par  1e  Laboratoire  Central  de  Recherche  de  THOMSON-CSF  et  appllqute  dans  les 
Divisions  ‘hallltalres*  du  groupe.  Son  Intfrit  est  d'tllalner  deux  points  gtnants  pour  les  applications  lA 
eabarqutes  ; 

-  1'lnterfagage  entre  langages  syabollques  et  classiques, 

-  la  ntcessitt  du  rtcuptrateur  ataoire  dans  la  aachlne. 

La  atthodologle  s'appule  sur  un  outll  de  haut  niveau,  appurtenant  1  1a  faallle  gtntrique  SPOCK,  peraettant 
de  proctdurallser  les  systtaes  experts. 
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AVANTAGES  : 

I 

-  gcstlon  totalt  de  1*  afMirc, 

-  latioagc  cible  C  ou  ADA  :  Intcrfafage  facile  avec  la  partle  conventlonnelle  da  1 'application, 

-  portage  parfonaant  sur  las  nchlnas  classiquas. 


RESERVES  : 

-  I'outll  ast  actuallaaant  1  I'dtat  da  prototype. 


3  L'OUTIL  SPOCK 

SPOCK  ast  Issu  da  racharchas  au  laboratoira  *SystiBas  Experts*  du  Laboratoira  Central  da  Racharchas  da 
THOMSON-CSF,  aendas  sur  la  c<ati1latlan  das  bases  da  connalssances  pour  rdpondra  aux  besofn  das  brancbes 
■lUtalras  da  THOMSON-CSF  an  systdaas  experts  teaps  rdel. 

La  co^)11at1on  das  rdglas  ast  apparue  coaaa  (tant  la  clef  da  I'obtantlon  da  parforaancas  diavdas. 
L'approcha  sulvie  paraat  da  procddurallsar  totalaaent  la  Tangaga  da  rdglas  (logiqua  du  praalar  ordre)  dans 
la  langaga  cibla. 

L'algorlthae  da  RETE  (principa  da  base  da  OPS-V,  ART  at  Knou! adga-Craf t)  a  dtd  dtandu  pour  coapHer  tota¬ 
laaent  la  parcours  du  rdsaau  da  flltraga  dans  la  coda  correspondent  au  Tangaga  clbTa.  Diffdrents  langages 
clbTas  pauvent  dtra  adressds  ;  LISP  at  C  sont  disponibles,  LTR3  puls  ADA  sont  an  cours  d'dtude. 

SPOCK  ast  : 

Un  exdcutif  da  systdaas  experts  rdpondant  aux  basolns  das  applications  teaq>$  rde1,  grSca  i  deux  services 
of farts: 

-  aaTtrlse  da  1 ‘allocation  adaolre  sans  ndcessltd  da  'garbage  collector*, 

-  prlaltlves  de  coaaunicatlon  avec  1‘extdrlaur. 

SPOCK  ast  hdritlar  de  : 

-  OPS-V 

*  prdponddranca  du  chalnage  avant  dans  las  rdgTes 

*  raprdsantatlon  das  objats  par  das  vactaurs 

*  flltraga  par  rtlgorltlxna  da  RETE 

-  ART 

*  phlTosophla  d'intdgratlon  de  pTusleurs  paradlgaes  sur  un  noyau  de  type  OPS-V 

-  ML 

*  Tangaga  de  prototypaga  utlTlsd  pour  1‘dcrltura  du  co^)1T8teur  de  rdgTes 


SPOCK  a  das  points  originaux  : 

-  las  rdglas  portent  sur  das  objats  abstralts  qui  pauvent  dtra  reprdsantds  par  n'leporta  queTTa 
structure  du  langaga  cibla  Idefstruct  ou  flavors  an  LISP,  record  an  ADA,  struct  an  C,  ...), 

-  coaqillatlon  totale  das  rdgTes  :  la  rdseau  da  RETE  n'axista  pas  d  T'axdcutlon,  Te  parcours  du  rd- 
seau  a  dtd  coiMilTd, 

-  exdcutlon  'garbage-free*  garantia,  tant  qua  Tes  rdgTes  ne  conq>ortant  pas  d'appeT  expTIcIte  d  LISP. 

-  rdgTes  aunles  d'una  priorltd  nuadrlque,  solt  statique  solt  dynaulqua,  cad  caTcuTde  d  partir  das 
varlabTes  du  ■ieaR>re  gauche  de  Ta  rdgle. 

-  raprdsantatlon  soupTe  des  objats,  adaptde  d  I'lapTantatlon  uTtdrIeure  des  ladcanisiiies  de  gestlon 
d'hypothdsas. 

-  coapllatlon  optimla  du  quantiflaur  existantfel  ;  possIbITIte  de  rdordonner  las  prdMisses  dans  Tes 
rdgTes  pour  optlalser  Tes  tests  effectuds  d  T’exkutlon,  d  partir  da  statlstiquas  d'utlTlsatlon. 

-  appal  d'una  fonctlon  da  coanunlcatlon  aprds  cheque  cycTe  d'infdrence  pjur  prise  an  coupta 
d'dvdneMants  extdrieurs  ou  gdrar  un  dchfancler. 
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SPOCK  (St  perfortMnt  : 

Un(  c<mf*rt1soB  dt  SPOCK  (vec  d'tutres  outIU.  pour  1*  resolution  d'un  probliae  de  pUnlflcotlon  utilise 
psr  U  NASA  pour  quontifler  Ins  porfonMnces  do  tols  outlls  et  dos  MChlnos  qui  les  supportcnt  (*Nonk(y 
and  banonos*,  30  rdgles)  a  ponds  d'etobitr  1o  classeaont  sulvant: 


OUTIL 

(version) 

TOOL 

MACHINE 

(a«B0lre) 

(■awry) 

Nb  rdgles 
ddclenchies 
Fired  rules 

Teaps  en 
secondes 
Tlae(s) 

Nb  rigles 
par  sec. 
Fired  rulcs/s 

SPKK-C 

(¥1) 

SUN  (RISC) 
4-260 

82 

0.03 

2733 

SPOCK-C 

(VI) 

SUN 

3-160(4Ma) 

82 

0.14 

586 

SPOCK-LIsp 

(VI) 

SUN 

3-160(4Mo) 

82 

0.18 

455 

SPOCK-Flavors 

(VI) 

SYMBOLICS 

3620(BHo) 

82 

0.31 

259 

ART 

(V2) 

SYMBOLICS 

3640(4Mo) 

86 

1.2 

72 

OPS-V 
(DEC  V2) 

VAX 

11/780 

81 

1.3 

62 

OPS-V 
(Forgy  V2) 

SYMBOLICS 

3640(4Mo) 

81 

1.7 

48 

ART 

(V2) 

TI  Explorer 
{4Mo) 

86 

2.4 

36 

La  prograaMtlon  das  rdqles  pour  les  autres  outlls  quo  SPOCK  a  ete  reallsoo  par  la  NASA. 

Conaontal ros  ; 

Lo  rapport  de  perfonaanco  entro  SPOCK  et  OPS>V  a  deux  raisons: 

-  1e  rdseau  de  flUrage  est  represente  dans  OPS-V  sous  fonae  d'un  al cro-propraaae  Interprete,  tan* 
dis  que  pour  SPOCK  1e  parcours  du  rdseau  est  totaleaient  coaqilie. 

•  1e  tralteaent  des  suppressions  et  des  nodlflcatlons  d'objets  est,  dans  SPOCK, une  varlante  orlgl- 
nale  de  Valgorlthaw  de  RETE,  avec  de  plus  la  aiodlflcatlon  des  objets  "en  place*,  c'est  a  dire 
sans  copie,  central reaient  i  OPS-V. 

Ces  aieaies  raisons  expllquent  une  partle  de  I'avantage  de  SPOCK  sur  ART  -,  une  autre  part  est  attrlbuable  i 
I'aliegeaient  de  certains  trafteaKnts  dans  SPOCK  par  rapport  a  ART  (pas  de  test  d'unicite  i  cheque  Inser¬ 
tion  de  fait,  par  exeaqilel  ;  en  contre-partle,  certalnes  solutions  acceieratrices  operatlonnelles  dans  ART 
(recherche  en  arisKilres  locales  par  hachage  djrnaailque  sur  les  tests  d'dgalltd,  par  exeaq>1e)  ne  sont  pas  en¬ 
core  l^plantdes  dans  SPOCK. 

Les  teagis  de  SPOCK-LIsp  dependent  de  la  representation  des  objets  sur  lesquels  s’appllquent  les  rdgles. 

Sur  SYMBOLICS,  de  nellleures  perfonaances  auralent  pu  etre  obtenues  en  utlllsant  des  'defstruct'  plutdt 
que  des  “Flavors*. 

La  slaillarlti  des  perfonaances  de  SPOCK-LIsp  et  SPOCK-C  dans  ce  test  est  due  i  ('absence  d'opdrattons 
arlthaietlques  qui,  en  LISP,  deaunderalent  des  tests  de  Vpe  i  1 'execution. 


3.1  CYCLE  O' INFERENCE  OE  SPOCK 

Le  cycle  d'lnference  de  SPOCK  canq)Orte  quatre  phases  : 

-  une  phase  de  ftUrage  (I)  (“pattern  autchlng*),  qui  dHerirtne,  I  ,>art1r  de  1'enseafele  courant 
des  objets  (*work1nq  aieanry*)  et  de  1'ensead>1e  fixe  des  rigles,  I'enseable  des  regies 

Instancldes,  c'est  a  dire  des  uplets  de  la  fonae  :  (rdgle,  objetl . objetN)  fonads  d'un  noai 

de  rdgle  et  d'une  coaiblnalson  des  objets  qui  satisfalt  le  mabre  gauche  de  la  rdgle. 

-  une  phase  de  sdlectlon  (2)  (’conflict  resolution*),  qui  ddterarine  I'lnstance  de  rdgle  de  plus 
forte  prlorltd  ;  en  cas  de  priorltds  dgales.  le  choix  est  aldatolre. 

-  une  phase  de  ddclencheawnt  (3),  qui  consiste  i  exdcuter  la  partle  drolte  de  la  rig1e  silectlon- 
nde  sur  les  objets  de  ('Instance,  ce  qui  a  pour  effet  de  laodlfler  1'ensead>1e  des  objets  et/ou  de 
coaaaunlquer  des  actions  au  annde  extdrieur. 
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-  uM  plus*  de  coaunlcitlofl  (4),  «i<  consUte  i  tiifcuttr  U  fonctlon  coawnlcttlon  ;  cettc 
fonctlon,  qui  p«r  difiut  ne  f«1t  rlen.  est  1  redffinir  per  1 ‘ut111s«tiur,  per  exeapic  pour  es- 
servlr  un  objet  horloge  1  une  horlope  exteme.  prendre  en  coapte  des  aodlflcetlons  extemes 
(ecqufsitlon  de  donndes  en  teaps  rfel),  pfrer  un  ichiencler, . . . 


Fonctlonneaent  du  cycle  d'infdrence  : 

SPOCK  celcule  I'enseable  des  rdgles  fnstencldes  de  fefon  tncrdeentele,  i  cheque  cycle  d'fnfdrence.  Le  phe- 
se  1  de  ftitrege  correspond  done  )  des  celculs  de  alse  i  Jour  de  I'enseable  des  confllts,  qui  ont  lieu  en 
rdelltd  eprds  cheque  aodificetlon  de  I'enseable  des  objets,  e'est  1  dire  pendent  les  pheses  3  et  4. 

Dens  Vdtet  Initlel,  I'enseable  des  objets  et  I'enseable  des  riples  Instenclies  sent  vides.  A 
1 'Inltlellsatlon.  piusleurs  objets  sent  Insirds  dens  le  adaoire  de  trevell,  ce  qui  peut  provoquer 
1 'Instencletlon  de  piusleurs  repies  qui  sent  plecdes  dens  1'epende.  Au  ddaerrepe  du  cycle 
d'infdrence,  1'fnstence  le  plus  pHorltetre  est  ddclenchde  :  ces  ectlons  aodiflent  dventuelleaent  le  ad- 
aolre  de  trevell-et  consdqueaaent  1'epende,  per  flltrepe-,  et  1e  cycle  se  poursult  Jusqu't  ce  que  I'une 
des  conditions  sul rentes  se  prdsente  : 

-  1  I'dtepe  de  sdlectlon,  1'epende  est  vide  :  11  y  e  errdt  du  cycle  ; 

-  pendent  1es  pheses  3  ou  4,  le  fonctlon  'belt*  est  eppelde  :  11  y  eure  errdt  du  cycle  t  le  phese 
de  sdlectlon  sulvente  : 

-  pendent  1'une  quelconque  des  pheses,  une  Interruption  se  prodult  (breek  ou  erreur)  :  11  y  e  er¬ 
rdt  leaddlet  du  cycle. 

Dens  ce  dernier  ces,  le  reddaerrepe  du  cycle  est  possible  per  le  fonctlon  ‘restert*,  t  condition  de  res- 
teurer  un  dtet  cohdrent  per  1'eppel  de  le  fonctlon  ‘cleerendeetch’. 

Dens  1e  ces  d'eppllcetlons  de  systdaes  experts  teaps  rdel,  11  convient  d'inclure  le  cycle  d'infdrence  dens 
une  boucle  plus  pdndrele  d'ettente  ou  de  pestlon  d'inforaetlons  extdrieures,  qui  neraette  de  relencer  eu- 
toaetlquesent  le  cycle  d'infdrence. 


3.2  LES  OBJETS  GERES  PAR  SPOCK 

Les  objets  sur  lesquels  portent  les  rdgles  sent  des  structures  aunles  d'opdretlons  ebstreltes  pour  le 
crdetlon,  1e  test  de  type,  I'lnspectlon  et  1 'effectetlon  des  ettrlbuts.  En  LISP,  les  objets  peuvent  dtre 
reprdsentds  per  n'leaorte  quelle  structure  ddfinie  per  'def street*,  ou  une  extension  per  des  objets  aunis 
de  veleurs  eetives,  ettecheaent  procddurel,  hdriuge  aultiple . .  per  excaple  les  Flevors. 

Les  rdples  sont  pdndriques  et  fonctlonnent  Inddpendeaaent  de  toutes  les  cereetdristiques  des  objets  de 
1 'eppllcetlon. 

Dens  les  versions  2  et  3  de  SPOCK,  les  essertlons  lopiques  peuvent  dtre  reprdsentdes  i  Telde  de  felts  vd- 
rlflent  un  test  d'unicltd  ;  les  felts  sont  des  objets  Internes,  qui,  i  Tlnverse  des  objets  ebstrelts,  ne 
peuvent  pes  dtre  pertepds  evec  le  reste  de  I'eppllcetlon. 

Un  exeaple  d'objets  est  donnd  eu  chepitre  4.2.2. 


3.3  LES  REGLES  GEREES  PAR  SPOCK 

Leur  coaplexltd  verlere  evec  les  versions  successives  de  SPOCK. 

Le  version  1  de  SPOCK  coaporte  des  rdqles  de  type  chelneqe  event.  Les  rdgles  possddent  un  noa,  une 
priorltd,  une  pertle  gauche,  une  pertic  droite. 

Le  pertle  geuche  expriae  une  condition  sur  le  adaoire  de  trevell  (dens  un  lengege  de  type  logique  du  pre- 
aler  ordre). 

Le  pertle  droite  expriae  les  actions  i  entreprendre  lorsque  1a  partle  gauche  est  vdrifide. 

Une  rdgle  s'appamnte  1  une  laqillcatlon  logique  de  la  forae: 
u  Oi:ti...  U|j  Ojjitj^  actions 

dens  1eque11e  1es  objets  o,  de  type  t,  sont  quentifids  per  p.  -,  universelleaent,  existentlelleaent  ou  nd- 
getlveaent.  '  ' 

Les  types  des  objets  sont  expriads  per  des  schdaes  ('petterns*) 


Des  exeavles  de  rdgles  sont  donnds  au  chepitre  4.2.3. 

Le  version  2  de  SPOCK  offre  de  plus  un  systdae  de  aelntlen  des  ddductlons  (Truth  Malntenence  Systea)  et  de 
structuration  de  1a  base  de  rdgles  en  paquets.  ~  ~ 
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U  v*rs<on  3  offriri  des  fonct1onMl1t<$  pour  ttnicturer  I'enseriile  tfes  ftfU  on  une  hiirarchle  de  contex- 
tes  et  explorer  en  pertIUle  plusleurs  Kypothdset. 

3.3.1  LES  MENBRES  6AUCHES  OES  REGIES. 

Le  Mubre  gauche  d'une  rdgle  est  une  conjonctlon  de  conditions. 

Une  condition  peut  itre: 

-  un  schdaa  quantifli  unlverselleaent.  exlstentlelloaent  ou  ndgatlveuent, 

-  un  appel  i  LISP  correspondent  i  une  condition  satisfalte  si  le  rdsultat  est  different  de 
nil,  fausse  sinon, 

-  une  liaison  de  variable  3  la  valeur  d'une  expression  LISP,  correspondent  I  une  condition  tou- 
Jours  satisfalte  (afin  de  letaorlser  le  rdsultat  d'un  calcul  Intenaddlalre). 

Les  schiuas  sont  par  ddfaut  universelleaent  quantlflis. 

La  quantification  existentlelle  est  reptrde  syntaxlqueaent  par  le  uot  cld  exists  devant  le  schena. 

La  negation  est  repdrde  par  le  uot  cld  not. 


Exeuple  : 

CondItlonsLIst  : 

condition 

CondItlonsLIst  condition; 
condition:  pattern 

syabol ‘pattern 
EXISTS  pattern 
NOT  pattern 
STRING 

syibol '•'STRING; 


Un  schdna  exprlne  un  type  d'objet  sous  la  fome  d'une  conjonctlon  de  tests. 

Le  prenler  test  concerne  la  structure  I  laquelle  appartlent  I'objet.  Ce  test  est  cos^lU  avec  le  prbdicat 
typep  de  LISP,  qui  est  vral  si  I'objet  est  une  Instance  de  la  structure  ou  d'une  extension  de  la  structu¬ 
re. 

Les  autres  tests  portent  sur  les  chases  des  objets,  ou  sur  I'objet  tout  entler. 

Les  tests  sur  un  chanp  sulvent  le  non  du  chasq)  ;  11s  sont  fonaEs  ; 

-  solt  d'un  prEdIcat  prEdEfInl  et  d'une  valeur  (constante,  variable  ou  expression  LISP), 

-  solt  d'un  appel  i  LISP  de  la  forae  'predIcat  arg2...argN  qui  sera  coupllE  en  (predIcat  argl 
argZ...ar^)  ou  argl  est  la  valeur  du  chanp. 

Les  tests  sur  I'objet  tout  entler  sont  possibles  dans  les  appels  a  LISP  repErEs  par  le  not  call  E 
I'lntErleur  du  schEaia.  II  suffit  pour  cela  de  faire  apparaltre  dans  1 'expression  LISP  la  variable  self  qui 
est  HEe  i  I'objet  candidat  au  schEna. 


3.3.2  CONVENTION  SUR  L'ORORE  OES  TESTS 

Le  coapllateur  de  rEgles  ne  change  pas  I'ordre  des  prEnlsses  dans  les  rEgles,  nl  I’ordre  des  tests  dans 
les  schEnas. 

Le  casqillateur  partage  tous  les  noeuds  du  rEseau  qu'Il  est  possible  de  rendre  coeauns  E  plusleurs  regies 
sans  perturber  I'ordre  des  tests. 


3.3.3  LES  NENBRES  DROITS  OES  REGLES 

11s  reprEsentent  des  suites  d'actlons  E  exEcuter  dans  I'environneaent  des  variables  IIEes  par  le  aeabre 
gauche.  Une  action  peut  Etre; 

-  une  expression  LISP  quelconque  ; 

-  une  liaison  par  bind  de  variables  IntemEdlalres  E  des  valeurs  quelconques  ; 

-  une  action  prEdEfInIe  de  aodificatlon  de  la  nEaoIre  de  travail  : 

*  Insertion  d'un  nouvel  objet 

*  suppression  d'un  objet 


aodificatlon  d'un  objet.avec  et  sans  flltrage 
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3.3.4  LES  PIIIORITES  DANS  LES  REGLES 

Les  priorftjs  sont  des  vtleurs  niorfrfqucs  cnttires  ou  rEelles. 

La  prlorltf  d'une  rdgit  past  Atrc  statiquc  ou  dyiuortquc. 

Les  priorltds  (brnaalques  sont  dEfInles  par  : 

-  la  valour  d'une  variable  Ilie  dans  1e  aenbre  gauche, 

-  une  expression  LISA  quelconque,  pouvant  porter  sur  les  variables  lldes  du  aeabre  gauche. 

Les  priori tfs  dynaalques  sont  ivaludes  pendant  la  phase  de  filtrage,  dis  qu'une  Instance  de  rdgle  est 
trouvde. 

Les  priorltis  statiques  sont  difinles  par  une  constante  entlire  ou  prddifinie  (Mxlauai,  alnlnui, 
lawdlatc-flrlng). 

La  constante  liMdlate-flrlng  Indlque  que  la  rdgle  est  ddclenchte  dis  qu'une  Instance  est  trouvie.  Les  re¬ 
gies  eavlqyant  cette  priority  dolvent  respecter  quelques  precautions  d'eeplol  et  ttre  rtservEes  pour  des 
actions  slaples. 

4  APPLICATION  DE  SPOCK  :  ASSISTANT  TACTIQUE 

Les  travaux  en  cours  dolvent  peraettre  d'obtenlr  dans  un  prealer  teqrs  un  outd  d'assistance  t  la  prepara¬ 
tion  de  alsslons  de  type  reconnaissance  avec  un  heilcoptere  leger,  puls  une  aide  i  1a  navigation  dans  un 
chaagt  de  aenaces,  tenant  coapte  du  relief  grSce  i  une  base  de  donnees  cartographlque  aabarquee. 

L'expertlse  est  recuelllle  auprAs  d'un  Chef  Pllote  de  1‘Avlatlon  Legbre  de  VArabe  de  Terre  (ALAT). 

Les  probieaes  i  gdrer  sont: 

-  la  prise  en  coapte  de  I'lntervlslblllti  entre  I'hillcoptAre  et  les  bventuelles  aenaces  (avec  aellleure 
utilisation  possible  du  relief). 

-  1 'Intervisibllltb  hdllcoptAre-but  (cas  du  tir). 

-  1a  gdntratlon  de  trajectolres 

-  1e  filoUge  de  la  gfnfntlon  de  trajectolres  tenant  coapte  des  aenaces,  du  relief,  du  respect  de  la 
alsslon  (heure,  but). 

Pour  dCaontrer  I'lntArSt  de  SPOCK  pour  ce  type  de  probliaes,  un  siHlateur  aaquette  basA  sur  une  descrip¬ 
tion  toponyalque  d'une  zone  gtographlque  a  (tf  riallsi  sur  aachlne  STH80LICS. 

4.1  SINUUTEUR  POUR  L'ASSISTANT  TACTiqUE 

4.1.1  PARAMETRES  D'ENTREE 
L'utlllsateur  dtfinit  ; 

-  la  position  de  dCpart  de  1 'hel Icoptdre 

-  la  Vitesse  de  rhdllcoptAre 

-  la  destination  finale 

-  les  diffdrentes  aenaces,  syabollsdes  par  : 

*  leur  noa 

*  leur  position 

*  leur  portfe 

-  les  rigles  d'dvolutlon  de  1'envlronneaent  : 

*  1e  aalntlen  des  objectifs  (g<nira1eaent  atteindre  la  destination) 

*  la  coherence  des  prises  de  decision  avec  1'envlronneaent  (evlter  les  aenaces,  par  exeaple). 
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4.2  NETHOOE  DE  SIMULATION 

4.2.1  PRISE  EN  COMPTE  DU  CARACTERE  TEMPOREL 

L*  siNuUtlon  du  tops  x'opire  par  1<  gestton  d'un  objet  de  typ*  Horloge  qui  coMwrte  1 'InfonHtlon 
Tops.  Le  Tcmps  s'tncrfmnte  ptr  une  rigle  dt  pHorlti  alnlaui  quand  tous  les  objets  du  systdw  ont  ftf 
traltis  pour  i 'Instant  de  Te^is  courant. 

Le  aouveaent  des  objets  aoblles  s'opdre  de  la  alae  aanidre  par  une  rdgle  de  priorftd  atniaua,  quand 
1 'objet  se  truve  (tre  en  retard  sur  la  variable  Teaps.  Srtce  i  cette  priorlti  alnlaale,  le  aouveaent 
n'est  effectue  que  lorsque  tous  les  paraadtres  d'ajusteaent  du  dfplaceaent  (vltesse  et  cap)  ont  it(  post 
tionnds. 

4.2.2  STRUCTURE  DES  OBJETS 

La  s1au1at1on  aet  en  oeuvre  quatre  types  d'objets  (Flavors)  : 

-  Hdllcoptdre 

-  Destination 

-  Obstacle(s) 

-  Horloge 

Ces  objets  sent  constrults  1  partir  d'hdritage  des  objets  de  base  sulvants  : 

-  INTITULE  ;  chMp  NON 

-  HORLOeC  ;  chMp  TEMPS 

-  DIMENSION  ;  chaiM)  PORTEE 

-  POSITION  : 

*  chaap  X  ) 

(  position  dans  le  plan  horizontal 

*  chaap  Y  i 

*  chaap  Z  altitude 

-  VITESSE  : 

*  chaap  Vx  ) 

(  variation  de  position  horizontale  pour 
(  chaque  aouveaent 

*  chaap  Vy  j 

*  cheap  Vz  variation  d'altitude  pour  chaque  aouveaent 
Les  objets  ddfinitifs  sont  constrults  par  heritage  : 

-  OBJET  hdrite  de  ; 

♦  INTITULE 

♦  POSITION 

-  NOBILITE  hdrlte  de  ; 

*  VITESSE 

*  HORLOSE 

-  OBJET-MOBILE  hdrite  de  : 

*  OBJET 

•  HOBILITE 

-  HELICOPTERE  hdrite  de  OBJET-MOBILE 

-  DESTINATION  hirlte  de  OBJET 

-  OBSTACLE  h«r1te  de  : 

♦  OBJET 

*  DIMENSION 

REtWROUE  :  Les  Menaces  rdelles  seralent  de  type  OBSTACLE-MOBILE. 


4.2.3  REGIES  D'EVOLUTION  DE  U  SITUATION 

Les  rigles  sont  alses  en  forae  par  la  aacroconaade  DEFRULE  qui  prend  caaaa  arguaents  : 

-  1e  Noa  de  la  rigle  (r<ut111sab1a  par  1e$  outlli  de  trace  et  de  contrSle  d'exicutlon  du 
prograae) 

-  la  Priorlti  de  1a  rigle  (utIMsEe  pour  1e  classeaent  des  dEclencheaents  des  rigles  dans 
1 'agenda) 

-  1e  Corps  de  la  rdgle  ;  prEalsses  puis  conclusions,  reliEes  par  1e  syabole 
Regie  d'incrEaentation  du  leaps  : 

Cette  rEgle  ne  prend  en  coaqite  qu'un  objet  :  1'HORLOGE. 

(DEFRULE  INCREMENTATION  0 
H:-(H0RL0GE  TEMPS>Tps) 

♦ 

(MOOIFT  H  TEMPS  Tps)) 

REgle  de  dEplaceaent  des  objets 

(DEFRULE  MOUVEMENT  0 
0;-(08JET-H0SILE 
X*x 
r>y 
Z*z 
yx*vx 
Vy-vy 
V2*V2 

TEMPS-toa) 

(HORLOGE 

TEM>S-Tps) 

OTps  toa)  :1  'objet  est  en  retard  sur  1e  leaps 
♦ 

(MOOIFT  0  X-(+x  TX) 

Y*(+y  yy) 

Z*(+2  V2))) 

Regie  de  navigation  vers  I'objectlf  (destination) 

Pour  s'assurer  que  1'hElicoptEre  va  atteindre  I'objectlf,  on  coapare  son  cap  avec  raziait  de  la  droite 
joignant  sa  position  prEsente  et  celle  de  I'objectlf  ;  une  diffErence  trop  iaportante  se  traduira  par  une 
modification  de  cap  pour  raaener  la  dEviation  a  une  valeur  tolErable. 

(DEFRULE  VERS-OESTINATION  3 
H:«(HELIC0PTERE 
X»x 
T-y 
Vx»vx 
vy*vy) 

0:-(DESTINATI0N 

X*dx 

Y-dy) 

(>(-(ATAN  vy  vx)(ATAN  (-dy  y)(-dx  x))  )0.1) 

(MOOIFY  H  X-(*(C0S(ATAN  (-dy  y)(-dx  x))) 

(SqRT(+(*  X  x)(*  y  y))) 

Y-(*(SIN(ATAN  (-dy  y)(-dx  x))) 

(SQRT(t(*  X  x)(*  y  y))))) 


REgle  d'Eviteaent  des  obstacles(nenaces) 

Pour  Eviter  un  obstacle  (aenace),  on  considEre  en  premier  lieu  ceux  qui  se  trouvent  sur  la  trajectoire  de 
rhEMcoptEre  ;  I'Evtteaent  correspond  a  une  modification  de  cap. 

La  sElection  peut  se  faire  sur  deux  critEres  principaux  ; 

-  1'hEllcoptEre  se  trouve  dans  la  portEe  de  la  aenace  ; 

-  I'hElicoptEre  se  trouvera  dans  la  portEe  de  la  menace  dans  k  unitEs  de  Te^>s  s' 11  ne  change  pas 
de  cap  (n1  de  vitesse  ou  d'altitude). 

Le  premier  critEre  correspond  E  1 'apparition  d'une  menace,  soil  que  cette  demlEre  soil  mobile,  soil  qu'un 
changeaent  du  relief  conduise  E  une  intervisfbilitE  hElicoptEre-aenace  ;  ce  critEre  n'est  pas  encore  pris 
en  coapte  dans  le  siaulateur,  qui  utilise  le  deuxilae  critEre  avec  k«3. 
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01ff<rcntcs  str«t<9l«s  de  correction  de  trtjectoire  peuvent  itrc  alses  en  oeuvre  i  11  i  iti  dicldi  de 
prendre  cemt  nouveau  cop  1o  direction  de  la  tangente  au  cercle  de  portie  de  la  wnace,  au  point  o<  la 
trajectoire  de  1 'hillcoptire  auralt  du  couper  ce  cercle  de  portde  de  la  wnace.  La  rdgle  a'fcrit  done  ; 


(OEFItULE  EVUE-OBSTMXE  2 
H:-(HELICOPTEItE 
X>x 

Vx-vx 

Vy»w) 

o:*(obstm;le 

X*ox 

Y-oy 

PORTEE-pl 

«-(+(EXPT  (-  OX  (+  x(*  2  vx)))2l 
(EXPT  (-  oy  (♦  y(*  2  vy)))2)) 
(EXPT  p  2)) 


(MODIFY  H 

Vx-(*  (SORT  (+(EXPT  vx  2)(EXPT  vy  2))) 

(COS  (4^(ATAN  (-oy  yl(-ox  x)) 

(‘(SIGWW-IATAII  (-oy  y)(^>x  x)) 
(ATAN  (vy  vxll) 

(/  PI  -2))))) 

Vy*(*  (SORT  (+(EXPT  vx  2)(EXPT  vy  2))t 
(SIN  (+(ATAN  (-oy  yl(-ox  x|) 

(r(SIGNUH(-(ATAN  (-oy  y)(-ox  x)) 
(ATAM  (vy  vx)l) 

(/  PI  -2mn)) 


4.3  PERFORMANCES 

Pour  un  nonbre  d'obstacles  restraint  (mins  de  trente),  on  obtlent  des  perfoniances  coaorlses  entre  200  et 
250  rdgles  ddclenchies  par  seconde,  ce  qui  est  parfaltewnt  coherent  avec  les  risultats  obtenus  avec  1e 
benchaark  NASA  (cf  tableau). 


4.4  AMELIORATIONS  PREYUES 

La  partle  SiMlateur  prendra  en  coapte  la  notion  de  voliaae  de  menace  et  se  raccordera  a  I'Aqutpenent  de 
base  de  donndes  cartographlque  afin  de  prendr*  en  coapte  1e  relief  tent  pour  la  navigation  que  pour 
I'dvltewnt  des  wnaces. 
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RESUME 

Cec  ertlcle  pr^eeace  lee  prlacipelee  41fflcultBe  rencootrAee  lore  de  le  rBelleetlon  en  PROLOG  de  eyetBnee 
experts  dene  un  contexte  lodustrlel<  tl  nootre  le  oBceeeltB  d'une  extension  de  PROLOG  vers  un  lengege 
orlentB  objet  et  dicrlt  les  •Bcenlsaee  de  bese  devent  f  flgurer  pour  feclliter  le  progreaBetion  des  systi- 
■es  experts.  L'ertlcle  d^crlt  ensulte  l*envlroaneBent  constrult  sur  cette  extension  pour  peraettre  le  re~ 
prSsentetlon  et  I'exploltetlon  de  connelseences  sous  le  forae  de  rdgles  de  production.  Le  seconds  pertle  de 
l'ertlcle  prBsence  quetre  appllcetlons  rBellsBes  per  1*BSD  dens  le  doaelne  sBroneutlque  et  spetlel  :  un 
systBae  expert  d'alde  A  le  definition  de  llelsons  Alectronlques  dens  un  avion  (BAS1LE)»  un  systBae  expert 
d'aide  A  la  gestlon  des  batteries  utlllaAes  sur  satellite  (GIBUS),  deux  systBaes  experts  d'alde  eu  diagnos¬ 
tic  de  pannes  de  sous-systBaes  satellite  (SCAO  :  systBae  de  contrfile  d'attltude  et  d'orblte,  PCS  :  syatBae 
pour  I'allaentetlon  Blectrlque). 

Mots  cKs  : 

envlronneaent  pour  systBaes  experts,  systBaes  experts,  PROLOG,  lengage  objet. 


1.  -  LES  BBSOINS  D'UM  IRDUSTRIBL 

L'Electronlque  Serge  DASSAULT  (BSD)  s'est  IntBressBe  trBs  tBt  aux  techniques  d* intelligence  artlflclelle, 
pour  rBeoudre  des  problBaee  Industrlels  sens  solution  classlque  satlsfalsante  (tele  que  le  calcul  syaboll- 
que,  le  diagnostic  de  pannes  de  circuits  Blectronlques),  et  pour  le  aaquettage  de  systBaes  coaplexes. 
L'utlLisation  crolssante  de  ces  techniques  dans  de  noabreuses  applications  a  fait  apparaltre  le  besoln 
d'outlls  opBratlonnels  dont  les  caractBrlatiques  Btalent  les  sulvantes  : 

-  aultl-doaalnes  :  aide  B  la  conception,  ’’aonltorlng**  et  survelllence,  diagnostic  de  panne,  planiflca- 
tlon, . . . 


-  aultl-techniques  :  loglque  des  prBdlcats,  systBaes  B  base  de  rBgles  de  production,  loglque  floue,  pro- 
graaaatlon  objet,  ... 

-  flable, 

-  docuaentB, 

-  ouvert  sur  I'environneaent  loglclel  existent, 

-  disponible  sur  les  aoyens  Inforaatlques  de  I'ESD  pour  facillter  la  diffusion  des  applications  au  seln  de 
I'entrepriae,  et  dans  un  envlronneaent  PROLOG,  le  langage  de  base  retenu  pour  noa  dBveloppeaents  en  In¬ 
telligence  artif Icielle* 


II.  -  COMMENT  DEVELOPPER  DES  STSTEKES  EXPERTS  EN  PROLOG 

Blen  que  la  prograaaatlon  des  systBaes  experts  apparalsse  souvent  coaae  un  domains  d'appllcatlon  prtvllBglB 
du  langage  PROLOG,  beaucoup  de  tentatlves  d'utlllsatlon  de  ce  langage  dans  ce  doaalne  se  sont  soldBes,  sl- 
tton  par  un  Bchec,  tout  au  aolns  par  beaucoup  de  dBsllluslona.  On  a  pu  alnsl  entendre  dire  que,  blen 
qu'lncorporant  un  aoceur  d'lnfBrencea,  PROLOG  offralt  dee  aBcanlsaes  de  ralsonneaent  Ineufflaanta,  qu'll  ne 
peraettalt  pas  I'Bcrlture  de  aBta-rBgles,  qu'll  n'Btalt  paa  asset  perforaeot. • . 

Ces  points  de  vue  contradlctolres  tlennent  au  fait  que  plualeurs  approches  aont  envlaageables  en  ce  qut 
concerns  I'utlllsatlon  de  PROLOG  pour  le  dBveloppeaent  de  systBaes  experts  ;  nous  ellons  les  passer  rapide- 
ment  en  revue. 

-  PROLOG  :  langage  de  spBclf Icatloo 

Dans  cette  approche,  le  systBae  expert  est  prograaaB  dlrecteaent  en  PROLOG.  Les  connslssances  sent 
repcBsentBea  par  des  sxloaes*  Le  ralsonneaent  ais  en  oeuvre  est  celul  fournl  par  le  langage  lul- 
aBae,  c'est-B-dlre  le  chalnage  arrlBre  avec  recherche  en  profoodeur  d’abord.  11  eat  clalr  que,  el 
I'on  e'y  cantonne,  cette  faqon  de  procBder  possBde  de  noabreux  InconvBnlents  qul,  aBae  au  prlx 
d'extenalona  telles  que  celles  figurant  dans  APES  (HAMMOND  64 J,  llaltent  forteaent  lea  posslbllltBa 
des  systBaes  experts  alnsl  dBveloppBs  : 

.  pas  de  structuration  de  la  connalssance, 

.  stratSgie  fixe, 

.  expression  des  aSta-connalssances  difficile, 

.  abcence  de  retour  arrlBre  Intelligent... 
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*  PI0L06  t 

PROLOG  Mt  lei  utlll»4  co«M  ufi  UngAge  giaftral  4*  progiUMtlMi  ;  e«la  conduit  i  tfflnlx  \a  fomo- 
11«M  do  roprdMatotloo  ot  d'ai^loltatlon  doo  cooiiAtsMoe**  (ou  tout  tlaploaoiit  4  roproodro  ua 
forMltoM  ddja  «sist«QC  t«l  quo  BffCM  [tCLLB  Sl)»  0PS5  [FOBGT  81],  SNAIK  [LADRIBEE  63],  TANGO 
{COKDIBE  83]«*«)  ot  A  I'laplteootor  on  PtOLOG-  C*oot  co  quo  l*on  oppollo  un  "ohell"*  Cotto  adthodo 
prdoonto  I'aoontogo  do  poraoccro  uno  lapldaontotloo  trio  ropldo  on  roloon  do  lo  pulsoooco  do  PBOLOG 
on  tont  quo  longoge  do  progrosMtlMk*  Par  contra,  I'offlcaclti  rdauUanto  n'oat  paa  garantio  ot  la 
roprdaoncacion  doo  conoaiaaancca  no  pout  a'offoctuor  qu'A  travora  lo  foraallaao  cbotal  co  qui  oat 
aouvont  inaufflaant* 

*  Istonatona  do  WHjOG 

Cotto  trolaldao  volo  conalato  A  prondro  aeto  doa  Inaufflaancoa  do  PROLOG  ot  A  ddflnlr  uno  oxtonaloa 
du  langago  offrant  oa  foactionnalttda  ndcoaoairoa  A  la  cdaliaacton  do  ayatAaea  oxperta.  Do  noa- 
broux  trauaux  ont  vu  lo  Jour  aur  co  thAao,  la  plupart  vlaant  A  intcodulro  doa  poaalbllltAa  do 
acruccuratloa  do  la  coanalaaonco  ot  do  contrOlo  Ax  ralaonneaont  [DIHCBAS  83),  [CLARK  82],  [OGAHA 
84].  Blon  qu*aucuo  do  coa  traoaux  n*alt  attaint  lo  atade  Induatrlol,  un  eartaln  noabro  do  prlnclpea 
ont  8t(  dtablla  : 

.  PROLOG  dolt  roator  un  aouo-'onaoablo  du  nouooau  langago  diflnl, 

.  lea  ostonalona  doloent  avoir  uno  adaantlque  parfaltoaent  ddflnle, 

loa  oxtonalona  dolvoot  offrir  doa  adcaniaaoa  puiaaanta  (aupdrleura  au  alaple  ajout/rotralt  do 
elauooa)  poraottant  la  ddftnltion  ot  la  nodlflcatlon  do  baaoa  do  connaiaaancea. 

Confrontda  au  problAao  do  la  r€allaaclon  do  ayatAaea  oxporta  dana  un  contexto  opArationnol,  noua  avona  dA~ 
voloppd  I'onvlronnoaont  RMICAT  (TAILL18BRT  86]  on  noua  appuyant  aur  la  trolalAao  approcho  (extonalona  do 
PROLOG)  ot  on  oaaayonc  do  aettro  l*accont  aur  lea  fonctlonoalltda  ndcooaalroa  au  diveloppoaont  do  ayatAoma 
oxporta  dana  uo  contoxte  laduatrlcl  A  aavolr  : 

-  poaalblllcA  d'lapldaenCor  uno  largo  gaaae  do  foraallaaoa  do  roprdaoatatlon  do  connaiaaancea, 

'  facllitda  pour  la  ddfinlclon  do  acratAgloa  proproa  aux  problAaoa  A  traitor, 

-  riallaatlon  rapldo  ot  pou  coGtouao  do  prototypoa  do  ayatAaoa  oxporta. 


III.  -  BMICAT 

EMICAT  oat  uno  oxtonaion  do  PROLOG  vora  un  langago  orionti  objot  (LOO)  aur  loquol  a  AtA  dlvoloppA  un  envi- 
ronnenent  pour  I'oxploltatlon  do  rAgloa  do  production. 

3.I.  Lo  langago  orlootA  objot 

Lo  UX)  ooc  booA  aur  lo  concept  do  •fraae**  [MINSKY  75]  (et  plua  prAclaAsent  aur  lo  «>dAlo  FRL  [ROBERTS  77 J) 
auquol  a  AcA  ajouCA  un  aAcaaiaao  do  coominlcation  entre  objeta  par  aeaBagea.  Lo  concept  d'objet  a*eat  avArA 
un  concept  A  la  foia  pulaaant  ot  officaco  pour  la  prAaentation  doa  connaiaaancea  factuelloa  ou  doa  ralaon-^ 
ncaenta  do  baa  niveau  dana  loa  ayatAuoa  oxporta  [FARCURS  83]. 

Par  allloura,  loa  poaalbllltAa  d'attacheaenta  procAduraux  (ou  rAflexoa)  ont  AtA  Atenduoa  afln,  on  partl'^ 
culler,  do  peraottro  uno  apAcif Icatlon  plua  prAclae  do  l*lnatant  do  dlclenchoaent.  Alnat,  A  tout  attrlbut, 
11  eat  poaalble  d*attachor  lea  procAdurea  aulvantea  :  al-boaoln,  avant-ajout,  aprla-ajout,  ovaot-retroit, 
aprAa^rotralt,  avant-aodlf icatlon,  aprAa-nodlflcatlon. 

Enfln,  cortalnoa  focllltAa  ont  AtA  introdultea  paral  leaquollea  : 

*  la  apAclf Icatlon  do  la  portAo  do  I'bArltago  (afln  do  gagnor  on  offlcacltA), 

•>  un  contrBlo  anti-boueloge  au  niveau  doa  ottachononta  procAduraux  pour  facilitot  la  prograwation  d'une 
atracAglo  do  cholnago  orrlAro  odoptAo  au  problAno  A  traitor, 

uno  trace  progroanablo  pour  I'oldo  A  la  alae  au  point  do  la  boae  do  connalaaaacea, 

-  un  «fcaolaae  do  sAnorloatlon  d'Atat  qul  felt  l*obJot  du  poragropho  aulvant, 

doo  prlaltlvoo  graphlquoa  pour  le  dAvolopponont  do  dialoguoa  hoaBO-aachlne  convlvlaux, 

-  un  Adltour  d'objoto. 

MtoorlMcion  d'Atat 

On  outil  do  dAvoloppoaont  do  oyatAaoa  oxporta  dolt  offrlr  loa  troia  oAconlaaea  do  choix  aulvanta 
[UORBltT  84]  : 

-  choix  do  I'Atot  our  loquol  agtr, 

'  choix  do  lo  rAgle  A  appliquor, 

'  choix  dea  objato  our  laaquala  appliquar  la  rAgla. 


V 
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L«  9t«ml*r  CM  cholx  %ftt  ie  plus  coQt^ux  k  Mttr*  •n  oeuvre  cer  tl  oftceeeite  une  ■iaorieetlon 
d'laforMiti<m  eouvent  leportentc  ;  11  est  eigalflcetlf  qoe  peu  d'outlle  de  ddveloppeeent  Ic  propoeuot* 

11  epperelt  que  el  ce  ■icealsee  eat  Iitc4sv4  eu  UM,  le  coneepteur  de  epetdae  expert  dlepoee  elore  d'un  ou* 
til  ilteeatelre  lul  peraettest  le  progreaaetioa  de  ecretdglee  edeptdes  eu  probllae  d  trelter.  Pour  cele, 
dene  BMICAT,  un  prototype  -  tuotmH  *<€01*  eet  prddiflnl  ;  d  tout  aoaeiit*  lee  opdretloae  effectudee  eur  lee 
objete  eont  adaorleiee  dene  I'loetence  de  ee  prototype  ddelgnde  coaae  "dtet  eourent”*  A  cheque  foie  que 
l*on  eouhelte  crier  uo  point  de  reroute  une  nouvelle  Inetence  de  I'objet  "itet'courent''  dolt  itre 
engeodrie.  II  eet  elnei  poeelble  de  afaorleer  tout  ou  pertle  de  I'erbre  de  recherche*  et  eneulte  de  e'y  di- 
plecer* 

Lee  Inforaetlone  aiaorleiee  dene  cheque  objet  et  oiceeeelree  eu  chengeaent  d*itec  eont  eccceelbles  d 
I'utllieeteur  et  peraettent  de  progreaaer  une  etretigle  od  per  exeaple*  en  cee  d'lapeeee*  le  eyetdae  re- 
toume  d  l*itet  eyent  engendri  un  ettribut  donni*  elnei  qu*on  le  trouve  dene  [VIALATTE  85]. 

Un  eyetdae  expert  n*eyent  pea  niceeeelreaent  d  recourir  eu  cholx  d'itet  dene  toutee  lee  pheeee  du  releonne- 
aent>  ee  afieenleae  peut  dtre  ale  bora  eervice  efin  de  ne  pee  pinelieer  I'eneeable  dee  recherchee. 

3<2.  L'eavlroaneaeat  pour  rdglee  de  production 

Un  LOO  oe  eufflt  pee  d  rielleer  un  eyetdae  expert  cer  beeucoup  de  conneleaencee  ee  reprieentent  plue  elei- 
aent  eous  le  forae  de  rdglee  de  production.  C'eet  pourquoi  BMICAT  coaprend*  conetrult  eur  le  couple 
PROLOG-LOO*  un  envlronneaent  peraettent  le  diflnltlon  et  I'exploitetlon  de  rdglee  de  production. 

Lee  rdglee  evec  naCAI 

Le  diflnltlon  d'un  foraelleae  de  rdglee  de  production  eet  eoualse  d  un  eneeable  de  contrelntee  bien  eouvent 
entegonietee  elnei  : 

-  le  foraelleae  dolt  dtre  puleeent  et  ginirel  aele  dolt  pouvolr  igeleaent  e'edepter  d  une  expertlee  perti- 

culidre  pour  peraettre,  ^ne  certelne  cee*  I'latroductlon  dee  rdglee  per  1 'expert  lul-adae* 

-  le  foraelleae  dolt  peraettre  I'icriture  de  rdglee  aele  euesl  de  aite-rdglee,  lee  prealdree  traltent  plu- 

tit  du  doaeine  d'expertlee  et  lee  eecondee  de  etretigles  de  recherche* 

-  le  foraelleae  dole  dtre  dicleretlf  aele  dolt  peraettre  igeleaent  I'expreeelon  de  connelssencee  d  cerectd- 
re  procidurel  (ecratigiee  de  recherche). 

Pour  tenir  coapte  de  cee  contrelntee*  une  rdgle  EMICAT  ee  reprisente  eoue  la  forae  d'une  conjonction  de 
buca  PROLOG. 

11  eat  clalr  qu'un  tel  foraallaae*  a*tl  convlent  bten  au  cognltlclen  en  lul  offrant  alnal  tout#  la  puleean- 
ee  dc  PROLOG,  ne  facllite  paa  lee  ichangee  avec  I'expcrt  at  en  aucun  caa  ne  lul  peraet  de  concevolr  lea  rd- 
glae  lul  alne.  C'eet  pourquoi  la  forae  "conjonction  de  bute  PROLOG"  ne  reprieente  quc  le  forae  Interne  dee 
rdglee.  Bn  pratique,  i'utlllaateur  peut  diflnlr  cheque  rdgle  coeae  un  objet*  hirltant  d'un  prototype  gini¬ 
rel  appcli  "rdgle”,  aunl  de  deux  attribute  dicrlveot  : 

-  I'un  le  "corpa”  de  la  rdgle  aoua  la  forae  la  aleux  edaptie  au  probldae* 

-  I'autre  la  "traduction"  d  appllquer  au  corpe  pour  le  traneforaer  en  une  conjonction  de  buta  PROLOG  (forae 

interne). 

Cette  approche  peraet  d'utlllaer  la  relation  hlirarchlque  entre  lee  objete  pour  diflnlr  dee  faalllee  de  rd¬ 
glee  dent  le  foraallaae  eat  adapti  au  type  de  connateaancee  i  reprieenter  ;  un  aiae  eyetdae  expert  pourra 
aloel  recourir  d  plualeure  foraaliaaee  ataultaniaeot . 

La  traduction  a'affectue  autoaatlqueaeot  d  I'entrie  ou  d  la  aodlflcatlon  de  la  rdgle  par  le  jeu  de  riflexaa 
pridifinla  birlcie  du  prototype  "rdgle”.  Grice  d  I'utllleatloa  dee  "opireteure”  prieente  dene  la  plupart 
dee  iapliacotetlone  de  PROLOG  cette  traduction  peut  reeter  elaple  tout  en  of franc  d  1' expert  un  foraallaae 
facile  d  aenlpuler. 

Coiut  "patler*  daa  rdglee 

L'laportance  dee  aite-connaleaattcce  o'eet  plue  d  diaontrer  [PITRAT  82]  ;  en  effet  dde  qu'un  eyetdae  expert 
attelnt  le  allller  de  rdglee,  lee  aiceniaaea  d'eppllcetion  qul*  quele  que  aolent  lee  adreaeagea  aaaoclatlfa 
ale  an  place*  reatent  eaaentielleaent  eiquentlele,  flnleeant  par  perdre  toute  efflcaclti. 

Pour  alder  d  la  diteralnation  dee  connaleeencee  utllee  d  le  rieolutlon  d'un  probldae*  BMICAT  offre  cinq 
poeelbllltie  pour  ae  rifircr  aux  rdglee  priaentee  dene  la  baee  : 

-  organlecr  lee  rdglee  eoua  forae  hlirarchlque*  ce  qul  eet  iHiidlat  grice  d  I .  repriecntetlon  objet  eur  le- 
quelle  ellea  eont  conetrultee  ; 

-  conetrulre  un  ou  plualeure  index  aur  una  claeae  de  rdglee*  la  conatructlon  eat  falte  autoaatlqueaant  au 
aoaent  de  I'entrie  de  la  rdgle,  d  partlr  de  ee  forae  interna  ; 

-  ee  rifirer  1  on  eneeable  d'ettrlbute,  celculie  d  I'entrie  de  la  rdgle  eur  oa  forae  Interne,  repirent  lee 
conetentce  qul  e'y  trouvent  aentlonniee  (objete,  typee,  attribute,  pridlcat  externe),  de  aenldre  conpara- 
ble  d  ce  qul  eet  felt  dene  (DAVIS  80 |  ; 

**  M  rifirer  d  dee  attribute  placia  par  le  ridacteur  de  la  rdgla  (par  exeaple  pour  Indlquer  le  eoOt  eu 
I'laportance  de  la  rdgle). 


-  effectuer  une  unification  ou  uo  filtrag«  «ur  la  corpe  da  la  rdgle  (forae  externe). 
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AvplicACloa  4m  riflM 

l*objcctif  principal  dm  BKICAT  4c«ic  dm  pmrmmttrm  1*  dtflaltlOD  dm  atratlsiaa  adaptiaa  «u  probltee  4  r4sou- 
dra  ;  cala  aat  caodu  poaaibla  frica  i  la  prlaltlaa  (unlqua)  4'appllcaCloo  daa  ciglea  ddcrite  au  paragrapha 
el-apria.  Calla-cl  aat  «ellla4a  mummt  Hmn  par  laa  atraedg^aa  prMiflnlaa  qua  par  laa  atratfiglaa  diflnlaa 
par  l*oetllaataur. 

Frloltlva  4'applieatlaa 

C'aat  UB  pridleat  qul  coaporca  trola  arguaaata  at  a*4crlt  : 

appliquar  (eholx^a-rigla*  chala^'objetf  objat-allactloimC) 

Chaqoa  aolutlon  oorraapood  4  uaa  Inataaclatiott  rduaala  da  I'uaa  daa  rdglaa  cholalaa*  laa  dlffdraataa  aolu- 
tlooa  aoot  obtamiaa,  cobm  e'aat  toujoura  la  caa  an  PROLOG,  4  chaqua  ratour  arrl4re  aur  la  prlaltlva*  La 
algaiflcation  daa  trola  arguaaata  aat  la  autaante  : 

-  la  ebolx~da*’r4gia  a'affaetua  an  donnant  aolt  la  Hate  daa  rdglaa  4  appliquar,  aolt  une  proprldtd  davant 
dtra  adriClda  par  callaa-ci, 

-  la  ehais-d'objat  aat  uaa  liata  da  ftltraa  paraattant  da  apdeiflar,  au  aonaat  da  I'application,  laa  objeta 
aur  laaquala  la  r4gla  dolt  a'appllquar. 

-  L'abjat-adlactiooai  paraat  unm  coaaurxlcatlon  antra  la  r4gle  at  la  ndcanlaM  d*  application. 

Alnal,  pour  "appliquar  laa  r4glaa,  adlactlonnda  par  laa  ndta-riglea  ml  at  a2",  11  aufflra  d*dcrira  ; 

appliquar  (t  ::  appliquar  (al.al.nll,  nll,g),nll,*) 

Stratdglaa  prdddflnlaa 

BMIGAT  offra  qualquao  atratdglaa  prdddflnlaa  conatrultaa  4  partlr  da  la  prlaitlaa  appliquar  ;  paral  eallea- 
cl  on  paut  eltar  : 

Paaaaga  dvaluatloo  da  toutaa  laa  aolutlona 

Saturar  draluationa  auccaaalraa  da  "paaaaga*  Juaqu'4  ca  qu'aueun  objat  na  aolt  plua  aodlfld  au  coura  d'un 

paaaaga 

Prouaar  application  Juoqu*4  aaturatlon  ou  ddaonatratlon  d*un  but  (eonjonctlon  da  buta  PROLOG)  fournl  an 
arguMBt 

Scraedfiaa  mtlUmmtmar 

Ca  n'aae  ol  par  haaard,  ol  par  oubli,  al  noua  n*avona  paa  ancote  dvoquf  la  cbatnaga  arrtlra*  En  affat, 
ealuWl  on  dolt  paa  Itra  eonaldird  conaa  un  aode  d' application  daa  r4glaa  (eallaa-cl  na  pouvaot  an  touta 
riguaur  a*appllquar  qua  dana  la  aana  condition  -  action)  nala  eoaae  una  atratigia  da  racharcha.  P'autra 
part,  I'axpdrlanca  acqulaa  par  la  rdaltaatlon  da  plualaura  ajratlaaa  axparta  noua  a  aontrd  qu'll  o'dtalt  paa 
rCallata  da  propoaar  un  chaioaga  arridra  "atandard”  du  fait  du  noabra  Head  da  cholx  poaalblaa  tela  qua  t 

-  la  racharcha  dolt  alia  aa  faira  ma  profoodaur  ou  an  largeur  d'abord  T  (ou  an  un  adlanga  daa  daux), 

-  dolt-on  ddclanchar  la  racharcha  pour  toua  laa  objata  7  (pour  cartalna  cala  n'a  aouvant  aucun  aana), 

-  quand  at  pour  quala  objata  dolt-on  poaar  daa  quaatlosa  4  I'opdrateur  7 

C'aat  pourquoi  11  noua  aanbla  qua  la  ddflnltlon  da  la  atratdgia  da  racharcha  an  arridra  aat  du  reaaort  du 
cogolticlcn.  EKICAT  offra  da  oonbrausaa  facllltda  poor  l«pl^**ntar  una  talla  atratdgia  ;  alnal,  par  axan- 
pla,  pour  rdallaar  la  ddaonatratlon  d'un  but  da  la  foraa  :  racharcha  da  la  valaur  da  I'attrlbut  d'un  objat 
donad,  an  profoodaur  d'abord,  aana  quaatloa  utlliaataur. 

11  aufflc  : 

-  da  prdaolr  la  gdndratlon  d*uo  indax  aur  laa  rdglaa  concluant  4  catta  valaur, 

-  d'attachar  4  I'objat  pour  laaquala  la  chatnaga  arrllra  aat  aouhaitd  un  rdflaxa  al-beaolo  qul  applique  laa 
r4glaa  obtanuaa  par  cat  index. 

at  c'aat  tout  I  La  racharcha  da  la  aalaur  da  I'attrlbut  ddclanchara  autOMClquasent  la  atratdgia  en  chalaa- 
ga  arrllra  ;  la  ayatdne  anti-bouclaga  lotdgrd  4  la  raprdaantatlon  objat  daitant  une  daentuella  racharcha 
ioflnia. 


IV.  -  APPLICATIOVS  AEKmACm^S  VT  mTIALES 

Dana  ca  chapltra  aoot  prdacntdaa  quatre  appllcatlona  da  EMICAT  dana  la  donalna  adronauttque  at  apatlal. 
d.l.  Alda  4  la  ddflnltlon  daa  llataoaa  dlaetroolquaa  (BASILS) 

One  pranldra  aaralon  da  BASILE  a  ltd  riallad  conjolntanent  par  I'BSD  at  La  aocldtd  AMD-BA,  pour  la  ddflnl- 
clon  daa  eonoaxlona  antra  dqulpananta  du  Spacdae  da  Naaigation  at  d'Araanant  d'aalona  da  conbat. 
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FoBeCioaaalltis 

L««  eonnczioa*  •ntr%  1««  4qulpc««ae«  d*ttn  •yzete*  d'zntt*  aodtrnc  doivent  retp«ct«r  de«  notMt  techniques 
qul  soot  I  le  foie  noabreueee  et  coaplezee*  D'eutre  pert»  lee  aodiflceclone  du  eysttee  aainent  I  tclier  dee 
iqulpeaeate  dijd  uttllede  1  de  ooueeeuz  iqulpeaente  dont  11  feut  epdeifter  I'lnterfeee*  Le  eyettee  KASILE 
epporte  eux  concepteure  une  aide  I  le  ddfinition  de  lleieone  entre  dqulpeacntei  en  eettent  I  leur  diepoei** 
cion  le  cooneieeence  dee  techaiclene  epieiellede  en  lleieone  dleetroniquee*  De  plue,  B4SILE  offre  d 
I'expert  le  poeeibllltd  de  aodlfler  et  d*eailiorer,  eene  Intervention  d'un  Inforaeticien,  le  beee  de 
connelseencee  le  aejeure  pertie  dee  conneieeencee  peut  elnel  ttre  eeieie  et  velidde  dlrecteeent  per 
1* expert. 

Cerectirlet Iquee 

BASILS  eet  un  eyetdae  interactif  od  I'etilleeteur  donne  dee  veleure  de  eereetdrietlquee  ddelriee,  ou  dee 
contreintee  eur  eee  veleure.  Le  reieooneaent  ^idd  per  lee  donndee  propege  elore  toutee  lee  coneSquencee  de 
cee  donndee  en  illainent  lee  eoluciooe  IneoapeCiblee.  Ce  proceeeue  inerSaentel  peraet  d'eboutir  A  tme  liei- 
eon  Mapldteaent  epBeiflde.  On  adcenleae  de  retour  erridre  Intelligent  penet  le  ■odifieetion  pertlelle  de 
le  solution  ea  ooure  de  coostructloa* 


el  nlveeu_logique  de  etet^loglque^ectif  de  eaetteur  eet  heut 
elore  tenelon  de  etet_^logTque^ectif  de  eaetteur  doit^etre  >  •  24 

el  E  eet^un  etet^logique 
et  ntveeir  de  E  eet  ieole 
elore  lapddenee  de  E  doitjetre  >  100  000 


4*2.  Geetlon  de  betterlee  de  eettelite  (OIBOS) 

Ce  eyeedae  eet  rdelled  per  I'BSD  (eoue-treiteote  :  SAFT  et  COCNITECH)  dens  le  cadre  d'un  contret  de 
I'Agence  Spetiele  Europdenne  (ESA). 

Fonetionnelitde 

Le  geetlon  de  betterlee  dee  eettelitee  en  orbite  beeee  eet  une  tiche  ddllcete  qul  ndeeeelte  une  expertlee 
epdclellede  dene  lee  eentree  de  contrdle.  En  effet,  lee  betterlee  d'eceuauleteure  epetleux  eont  dee  dqulpe- 
aente  pour  leequele  on  ne  diepoee  pee  de  aoddlieetlon  aethdaetique  du  coaporteaent,  euffleeaaent  gdnirele 
pour  dtre  epplieeble  dene  toue  lee  rdgiaee  de  foncclonneaent. 

Le  geetlon  de  betterlee  e  deux  objectife  : 

1)  effectuer  A  cheque  orbite  (durde  100  aln)  une  recharge  euffleente  dee  eccunuleteure  pendent  le  pdrlode 
d'dcleireaent  (65  aln)  efln  de  dlepoeer  de  eoute  le  puteeence  odceeeelre  A  le  pleteforae  et  eux  chargee 
tttllee  pendent  le  pdrlode  d'dcllpee  ()S  aln), 

2)  aexlaleer  le  durde  de  vie  de  le  battetle,  en  dvltent  lee  eurchergee  exceeelvee  et  en  prenent  en  coapte 
le  vleillleeeaeac  dee  eccuauleteure  dene  I'elueteaeot  dee  perealtree  de  geetlon. 

Lee  foncclone  du  eyetAae  expert  eont  : 

*  Le  "aonltorlng*  dee  aeeuree  de  cheque  orbite 

Le  eyetAae  Intdgre  A  Le  fin  de  cheque  orbite  un  certain  noabre  de  donndee  cerectdrletlquee  et  lee  quell- 
fie  :  eberrente,  noalnele,  eooraele.  En  rdglae  etetlonnelre  (utllleetlon  et  recharge  rdgullAree  de  le 
betterle)  le  eyetAae  dlebore  lee  veleure  ettenduee  A  I'eldc  de  aodAlee  expdrlaenteux.  En  rdglae  trenel- 
tolre  (cee  gdndrel)  le  eyetAae  felt  un  bllen  d'utilieetlon  et  de  recharge  eur  un  hletorlque  d'une  vlng- 
telne  d'orbltce.  Le  cee  dchdent  un  diagnostic  d'enoaelle  du  coaporteaent  de  geetlon  de  le  recharge  eet 
prodult  elnel  que  dee  coneelle  pour  corrlger  ou  coapeneer  I'enoaelle. 

'  L'eoelyae  i  long  terae  de  I'htetorlqoe  de  le  betterle 

Le  fonctlon  de  "aonltorlog”  conetruic  Incrdaenteleaent  un  hletorlque  eynthdtlque  dee  donndee  et  dvdne-* 
aente  laportents.  te  fonctlon  d'enelyse  foumtt  un  lengege  de  requAtee  de  cet  hletorlque  elnel  que  dee 
fooctlong  de  diagnostic  A  long  terae  concement  I'eetlaetlon  de  le  durde  de  vie  reetente  et  lee  ddgrede- 
tlone  de  pcrforaances. 

Cereetdrletlqoee 

Le  eyetAae  expert  trelce  cyellqueacnt  lee  donndee  de  I'orblte  courente.  Le  rvieooneaent  utilise  lee  donndee 
dee  orbltee  prdeddentee.  11  eet  done  ndceeeelre  de  reprdeenter  dene  le  beee  de  conneieeencee  : 

dee  felts  detde  (aeeuree,  concluelone  dee  orbltee  courentee  et  peeedee), 

**  dee  felts  Inetentende  (vrele  pendent  une  orbite)  et  dee  felts  eyent  une  portde  teaporelle  (vrele  pendent 
plueleurs  orbltee). 

Dee  prlaltivee  de  geetioa  de  cee  felts  out  dtd  rfelledee  eledaent  evec  le  LOO  de  EKICAT.  Lee  felts  peuvent 
dtre  utllisde  per  lee  dlffdrentee  fealllee  de  riglee  du  eyetAae. 
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it  «ad  ofjehartcjeurrcQt  im  •baorMl(«op) 
mod  kJTactor  is  ooslasl 

thsn  psrtlsl^sbortjclreulc  dstsctsd^urlot  chsrgs 
If  tsspsrscurs  <  10 

sad  sbs(tsa^rstars  *  ssi<tsapsrstQrs,  or5t  a*‘l))>2 
tbsa  ststs  Is  trsaslsnt 


4«3.  Oisgaostle  4s  psasss  4a  sous-srsedas  sliasacscloa  (K8) 

Cs  systdas  sxpsrc  s  it!  rdsllsd  cooiolacsasat  par  1*BSD  st  l'4drospstlsls/D8SS  (Cannes)  dens  Is  cadre  d'un 
eoncret  CtfCS. 

roaetlonaalltds 

Le  sous-systdae  PCS  du  satellite  TDpl,  rdgule  I'allnentatlon  ilectrlque  du  satellite*  Son  foncttonneaent 
est  done  de  nature  purcaeot  ilectrlque,  une  enoaslle  y  correspond  d  un  nleeau  Incorrect  de  tension  ou  de 
courant  sur  use  psrtle  du  sous-systdae  ou  d*un  dldaent  client  ellaentd* 

Lee  alsslons  deasndies  au  systdae  expert  eont  ou  aoabre  de  trots  : 

-  la  ddtectlon  d*anonalles,  c^est'^d-dlre  le  contrdle  fin  et  systdaatlque  de  toutes  les  tdlteesures  per  coa- 
perelson  d  des  vsleurs  noalneles*  Cellee-cl  sont  celeuldes  dynealqueaent  per  aoddlisetlon  en  fonctlon  de 
la  configuration  du  satellite  (ddteralnetton  d*un  dtst  de  rdfdrenee). 

le  diagnostic  de  pannes,  c*est~d-dlre  la  ddteralnatlon  des  coaposents  responssbles  des  onoaelles  dfitec' 
ties  et  si  possible  de  leure  aodcs  de  pannes. 

**  la  salsle,  le  aodlflcatlon,  la  consultation  dee  connelssances  per  un  expert,  non  spiclellsts  en  intelli¬ 
gence  ertlf iclelle* 

Caraccirlsttqoas 

Le  ditectloo  d^anoaellee  nicesslte  la  gestton  d'un  itat  de  rifirence,  c'est-d-dlre  les  tensions  et  coursnts 
de  toutes  les  llslsons  des  schiass  ilectrlques  et  done  les  vsleurs  thiorlques  des  tiliaesures*  d  cheque  ao- 
dlflcatlon  de  la  configuration,  cat  itat  de  rifirence  eat  recaleuli.  Les  eonnaisssnees  utllisies  consistent 
en  une  description  structurelle  du  sous-systdae,  sous  forae  de  hlirsrchle  de  bottes  rsllies  per  des  llsl¬ 
sons,  et  une  description  fonetlonnelle,  sous  forae  de  fonetions  de  trsnsfert  spiclflques  i  une  bolte  ou  gi- 
nirlques  pour  un  type  de  bolts  (risistsnee  par  exeaple).  Css  fonetions  reliant  les  coursnts  et  tensions  des 
liaisons  en  entrie  et  sortie  de  la  bolts* 

Pour  les  fuslbles,  la  fonctlon  de  trsnsfert  est  Is  suleante  : 


dene  fusible  oaji  el  itat  •  pesssac  elors  1(2)  :•  1(1) 


Des  rigles  de  csleul  de  psraodtres  pecaettent  de  cslculer  les  persadtres  utllisis  per  les  fonetions  de 
trsnsfert  (puissance,  risistsnee,  itat,**.)  en  fonctlon  des  carectirlstlques  de  le  bolte  ou  de  see  sous- 
Go^osents* 

Pour  ieeluer  le  pereadtre  *'itat*'  utlllsi  dens  la  fonctlon  de  trsnsfert  d'un  fusible,  on  applique,  per  exea¬ 
ple,  la  rdgle  de  calcul  de  pereadtre  suleante  : 


si  aode(fuslble)«noalnal 
nlors  itat(fuslble)  :•  psesant 
slooa  itat(fuslble)  :•  non^passant 


Le  eslcul  de  I'itet  de  rifirence  est  un  elgorithae  de  psreours  du  schiaa  exploltent  des  connelssances 
diclaretlees*  Les  enoasllcs  sont  ditecties  per  coapsreisoo  des  valeurs  de  tiliMSures  eux  esleurs  thiorl¬ 
ques  didultes  de  I'itet  de  rifirence. 

Pour  le  diagnostic,  les  connelssances  utllisies  consistent  en  un  enseable  de  rdgles  ettechies  d  cheque  bol¬ 
te,  peraettenc  de  didouener  (dlsculper)  la  bolte  et  tout  son  contemi,  ou,  ou  contrelre,  de  fairs  des  Iqrpo- 
thdses  de  psnnee  d  I'lntirteur  de  la  bolte*  Ces  rdgles  s'appulent  sur  la  norasllti/anorasllti  des 
tiliaesures  ou  sur  leurs  vsleurs  nuairlques*  II  s'egit  done  d'un  "coaplletlon*'  de  connelssances  de  aodill- 
setlon  et  de  coonalssances  des  pannes  possibles* 

Le  diagnostic  consists  d  percourlr,  de  feqon  descendsnte,  le  schiaa  en  a'appuyant  sur  la  description  struc¬ 
turelle  et  d  tenter  de  dlsculper  ou  suspecter  cheque  bolts.  Le  tiduetlon  et  corriletloo  des  hypothdses  de 
pannes  ridultes  sont  fsltes  par  calcul  forael  sur  les  expressions  loglques* 


blocl  MC_d44loimi_fll  tal  »  0*0 

oo  ta2  B  pals«aiiCtt<blocl)/aftX  (20.0,  tal) 

od  **«*'  •Ignlfla  i  peu  pria  At  od  blocl  oat  una  bolta  at  tal,  ta2  aont  daa  tblteeaurca 


4.4.  Dla^ftoatlc  4a  paanaa  4tt  aoua-ayatiaa  4a  eontrftla  4'atclto4a  at  4'orblta  (8C40) 

Ca  ayattaa  axpart  a  iti  r4alla4  eoaiolntaaaat  par  1*ESD  at  Hatra  Bapaca  (Toulouae)  daaa  la  cadre  d'un 
coat rat  CNES. 

PoDctlonaalltla 

La  aoua''ayat4ae  SCAO  du  aatallita  TELEGMl,  aaaura  la  poaltloaaaaaat  at  la  atablllaatlon  du  aatelllta  an 
orblta  gdoatatiooaalra*  Soa  foactlonnaaaat  aat  da  nature  I  la  fola  aicaalque  (dyoaalqua)  at  blactronlqua, 
lea  deux  aapacta  4tant  btroltaaeat  li4a  daaa  lea  bouclaa  da  pilotage  (roulia,  taagaga). 

Una  anoaalla  daaa  la  aoua^ayatdM  peut  aa  tradulra  par  un  dyafoactlonnaaant  puraaant  llectrlque,  par  exaB* 
pla  daaa  I'aliaentatioa,  ou  par  daa  phAnoabnaa  dyaaalquaa  ladCalrablaa  ayant  daa  aapacta  taaporala  at 
tranaitoiraa. 

Lea  alaalona  daaanddaa  au  ayatSaa  axpart  aont  au  noabra  da  trola  ; 

-  la  dlagnoatic  d*anoaallaa  :  partant  daa  uioaallaa  d4tact4ea  au  centre  da  contrSle,  il  a'aglt  da  localiaer 
la  panne  1  un  nlvaau  da  flaaaaa  coapatlbla  avec  lea  capacitia  da  reconfiguration  axlatantea  4  bord  (ce 
qu'll  aat  couCuae  d'appalar  "I'dlCaent  coaautable**). 

-  la  foraatlon  daa  opErataura,  par  I'intaraidlalra  da  facllltba  de  viauallaatlon  at  d*axploitation  dea  ral- 
aonsaaanta  at  d'accda  aux  conaalaaancaa> 

**’  la  aataia,  la  ■odlflcatloo,  la  conaultatlon  dea  conoaiaaancea  par  un  expert,  non  apgclaliate  an  Intelll' 
gance  artif iclalla. 

CaractCriatlquaa 

Da  laEne  qua  dana  la  PCS,  lea  coonalaaancea  ralatlvea  4  ce  aoua'-ayatboe  pauvant  ttre  claaadea  an  trola  cat£~ 
goriaa  i 

-  lea  achAmaa  du  SCAO  :  laur  daacription  eat  analogue  4  calls  du  PCS, 

'  lea  connalaaancaa  fonctlonnellaa  qui  dAcrivenc  lea  dApandancea  fonctionnallaa  antra  lea  dlvara  coneti*- 
tuanta  du  aoua-ayatAoa,  trola  types  de  conaalaaances  fonctlonnellea  aont  fournlaa  au  aystAne  : 

1)  Dan  lola  gAnlralaa  portent  aur  la  structure  du  aoua-'aystAne,  mala  IndApandantes  du  aous-ayatAtte 
conaldArA*  Par  exenple,  lea  rAglea  d'lnfluence  Alectrlque  : 


dana  lea  relel82^l,  on  a 
ai  poaitlon  ■  on 
a  lore 

entree(l)  an  aoda  M  Influence  aortle(3)  an  BOde  M 
alnon 

antrae(2)  an  node  M  influence  aortle(3)  aa  aoda  N 


Catta  rAgle  aat  una  rAgle  gAnAriqua,  alia  aat  valable  pour  tous  lea  relala  de  type  relal82_l.  Elle  ex- 

prliae  la  fait  qua  le  node  an  entrAe  ee  propage  en  aortle> 

2)  Dea  relatione  apAcifiquea  au  aoua-ayetAne,  non  dAductiblea  de  la  eodAliaatlon  atructurelle*  Bllee  por¬ 

tent  aur  lea  eonnaiaaancea  dynaniquea  an  foumlaeant  daa  relations  inpllquant  dea  variables  systAnea 
at  lea  tAlAmeaureS' 


roulia^reconatituA  en  aode  3 

eat^lnflueocAjMr  delta_jc_nolos  en  node  anomal, 

at  ■onent_cloAtique  en  node  anomal 


3)  Dea  can  4'exception,  qui  pemettent  da  prendre  en  conpte  daa  caa  particuliera  dana  la  structure  du 
aoua-ayatAne. 


>>  l«a  comulsaaoces  heurlatlques  <|ul  permetc«ot  d'orlenter  las  recharchea  aur  lea  ftl^aenta  lea  plua 
aoup^oooablea  (degr€  de  auapicloa^ 

Le  SCAO  eac  dicoupA  en  80ua*-eaae«blea  foactioanela  (dynaalquea  ou  blectriquea) •  Un  premier  diagnostic  est 
effactud  aur  la  aoua-anaaabla  du  SCAO  daaa  laquel  a  dtd  ddtaccda  la  praaldra  aaoaalla*  SI  la  panne  n'a  pas 
dtd  localiada  dana  ca  praalar  aoua-anaa»bla,  da  nouvaaux  dtagnoatlea  aont  lancda  aur  lea  aous-'anaeables  qul 
ont  una  Influanca  aur  I'anoaalta. 

La  calaonnaaant  A  I'lntdriaur  d'un  aoua-anaaabla,  conalace  A  Identifier  toutea  las  causes  possibles  de 
l*aaoa«lla  A  partlr  du  achd«a,  da  la  configuration  at  daa  ddpandancas  fonctlonnalles,  puls  A  construlra 
una  adquance  de  testa  aur  las  valaura  das  tdldnaauraa  parnettant  de  dlscrlnlner  las  causes  possibles.  Lea 
taata  axploltant,  an  prtorltd»  la  lista  das  anonalles  fournles  au  ddbut  du  diagnostic.  Par  la  suite,  le 
syatAae  Interroga  I'opdrataur  aur  la  valaur  das  cdldnaaurea  concerndes  par  las  tests. 


V.  00«CL08t0f 

Las  aystAaas  experts  prdsantda  nettent  an  dvldance,  pour  cheque  applications,  lea  spdclflcltds  des  connals'- 
sancas  at  dgalanant  daa  ralaonoanants  at  atratdgles  utlllads.  11  eat  blen  dvldent  par  allleurs  qua  ce  ne 
aont  pas  lea  adcanlanes  da  baaa  das  rAglea  da  production  (chalnage  avant  ou  arrlAra)  qul  peuvent  apportar 
una  solution  toute  falte  pour  rdallsar  l*enaanble  de  cas  systAnea. 

II  faut  done  disposer  d'outlla  ouverts  at  pulaaants  (de  type  EMICAT),  offrant  des  facilltds  pour  ooddllser 
la  base  da  connalssances  et  las  stratdgies  ddslrdas. 
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Un  processus  d'alde  3  la  decision  propre  a  tralter  la  saJorttE  des  problleies  de  choix  en 
presence  d'infonutlons  aultlples  est  elabori  i  partir  d'une  fonaulatlon  aussi  objective  et  exhaustive 
que  possible  de  ces  problimes.  Le  processus  dicrlt,  propre  i  itrt  IntSgri  dans  un  Systeae  Expert  capable 
de  gerer  dIffErentes  options  de  fagon  Interactive,  est  lllustri  par  une  application  i  la  classification 
■ultl-capteurs  de  cibles. 

Cette  application  penaet  de  discuter  le  coanorteeient  d'un  certain  nonbre  de  techniques  de 
fusion  de  donnies  pour  lesquelles  une  foraulatlon  adaptee  au  probleae  envisage  est  proposee. 

L'extenslon  de  ces  techniques  de  decision  }  un  processus  original  d'AI location  de  Ressources 
est  ensulte  prisentie  ;  elle  peraet.  2  partir  d'infonutlons  prealables  sur  un  certain  nonbre  de 
sUuatlons  2  analyser  sinultanmnt.  d'attrlbuer  le  traltenent  d'une  de  ces  situations  2  chacun  des 
Infomateurs  disponibles,  afin  de  foumir  la  nellleure  Evaluation  sur  I'enseoaie  des  situations.  La 
conparalson  des  dIffErentes  solutions  dEgagEes  est  abordEe  par  la  simulation  du  scEnarlo  de 
classification  dEJ2  utlllsE  prEcEdeaiaent. 


n  mnwiiiCTroN 


L' Intelligence  Artificlelle,  et  plus  particullerenent  les  Systenes  Experts,  sentient  devoir 
apporter  une  aide  appreciable  2  1 'Elaboration  de  choix  et  de  dEcIslons  dans  le  domalne  de  la  defense, 
que  ce  salt  pour  1 'analyse  de  situations,  ou  pour  la  planificatlon  d'actlons  2  mener.  Dans  tous  les  cas, 
leur  utilisation  requiert  la  mise  au  point  de  procEdures  d'agrEgatlon  d'lnfomatlons  d'origines 
diverses  pemettant  I'Elaboratlon  des  regies  de  decision,  Eventuellenent  stochastiques,  qui  dolvent 
allmenter  1eur  base  de  connalssance. 

Dans  ce  contexte,  1e  prEsent  exposE  propose  un  processus  d'aide  a  1a  dEcIslon  propre  a  tralter 
les  applications  ou  les  Informations  a  synthEtlser  pemettent  I'Elaboratlon  de  grandeurs 
caractErlstIques  de  la  confiance  relative  2  accorder  aux  dIffErentes  hypothEses  possibles,  rEpertorlEes 
2  priori.  Ces  grandeurs  peuvent  Etre  dSfInles  sous  forme  de  donnEes  Incertalnes,  qui  prennent  notanment 
en  compte  des  Informations  extErleures  relatives  2  I'envlronnement,  au  bon  fonctlonnement  des 
Infomateurs  utilises,  etc...  Le  processus  dScrlt  peut  utlllser  dIffErentes  lols  de  fusion  ElaborEes  2 
partir  de  techniques  garantlssant  transItIvltE,  associ atl v1 tE  et  relation  d'ordre  total,  telles  que 
1'InfErence  BayEslenne,  le  Maximum  d'Entrople,  la  ThEorle  de  I'EvIdence  dEveloppEe  par  Dempster 
et  Shafer,  la  ThEorle  des  Ensembles  Flous  de  Zadeh,  ou  une  approche  plus  dtrecte  de  classement 
statlstique  des  EventualltEs  envisageables.  Ces  dIffErentes  possIbllltEs  sont  coiM)arEes  dans  le  cadre  de 
leur  application  2  la  classification  multi -capteurs  de  cibles,  sur  la  base  de  la  simulation  d'un 
scEnarlo  typiRue. 

Un  tel  processus  de  dEcIslon  est  par  alHeurs  le  plus  souvent  bouclE  par  une  technique 
d'Allocatlon  de  Ressources  qui  ^flnlt  en  permanence  quel  moyen  d'analyse  dolt  Etre  affectE  au 
traltement  des  dIffErentes  situations  2  Evaluer,  afin  de  garantir  le  mellleur  rEsultat  global,  compte 
tenu  de  I'lnformatlon  dEJa  acquise.  Plusleurs  procEdures  susceptibles  d'arsurer  cette  fonctlon  sont  done 
proposEes  et  comparEes  sur  la  base  du  neme  scEnarlo  de  classification  lultl-capteur. 


II)  fawuLATiai  DU  pwmt 

ConformEment  2  la  figure  1,  le  problene  posE  suppose  que  I'on  acquiert  m  Informations  gj, 

J  C  [l,  MJt  et  que  Ton  peut  Etabllr  2  partir  de  chacune  d'elles  n  grandeurs  eij  ,  1  6  t.1,  n]  , 
reprEsentatIves  de  1'lmportance  ou  de  la  confiance  relative  qu'11  convient  d'attrlbuer  2  chacune  des  n 
hypothEses  N1  envIsagEes  2  priori,  au  vu  de  la  grandeur  gJ  consIderEe. 

Dans  le  cadre  de  cet  exposE,  les  grandeurs  Cij  ElaborEes  sent  supposEes  1 ndEpendantes  d'une 
Information  gJ  2  1 'autre  ;  cette  hypothEse  correspond  le  plus  souvent  2  un  choix  Judlcleux  (ou  une 
tranfonaatlonl  des  Informations  qui  garantlt  leur  mellleure  complEmentarltE. 
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Le  problene  pos£  consists  alors  I  chercher  Vhypothese  HI  qui  satisfalt  "au  nleux"  : 

(1)  max  {  eij  }  ,  y  j  . 

n  convient  done  de  reollsor  une  althode  d'agrigatlon  des  esj  par  rapport  aux  InforMtIons  j, 
eventuellaaent  apres  changeaent  de  sfgne  des  coaposantes  etj  pour  lesquelles  le  prob1£iiie  Initial  seralt 
celul  d'une  alnlalsatlon. 

Cette  aSthode  doit,  de  preference.  $tre  capable  de  tralter  1es  cas  oQ  1es  grandeurs  eij  sont 
Incertalnes,  e'est-a-dire  slapleaent  difinles  par  un  Intervalle  de  valeurs  possibles  t*ij'  ' 
afin  de  peraettre,  notaiaent,  la  prise  en  coapte  de  I'aptltude  d'une  Inforaation  a  eaettre  un  avis  sur 
une  bypothise  donnee,  et  done  de  la  surete  de  cet  avis. 

Le  processus  de  decision  gul  preside  au  cholx  de  1'bypothese  a  retenir  dolt  par  allleurs  prendre 
en  consideration  un  certain  noabre  d'lnforaatlons  utiles  sur  1 'envlronneaent  et  le  contexte  de 
1 'operation  aenee.  pour  etre  plelneaent  efficace.  Nous  supposerons  dans  1a  suite  que  ces  Inforaatlons 
sont  disponibles  sous  forae  de  diffjrents  Indices  que  nous  rasseablons  Id  de  fagon  synthStIque  selon 
trols  categories  fonct1onne11es  : 

a|  Oes  Indices  aej  de  qualite  de  1'lnforaatlon  gj,  qui  reprisentent  I'aptltude  de  cette 
Inforaation  i  tralter  le  probleae  de  decision  pose,  sa  robustesse  vis-a-vis  de  ce  probleae.  Typiqueaent 
un  tel  Indlce  peut  figurer  la  presence  de  broulllage  ou  de  leurrage  pour  une  mission  d'analyse  de 
situation,  une  eventual Ite  non  repertorlee  a  priori  panel  1es  hypotheses  HI,  I'effet  d'un  mauvals 
rapport  signal/brult  ou  d'une  attenuation  laportante  au  niveau  d'un  senseur.  Un  tel  Indlce  resulte  d'une 
analyse  appropriee  des  Inforaatlons  elles-aSaies. 

b)  Des  Indices  aij  de  conflance  ou  d'liportance  conferee  a  priori  a  I'lnforaatlon  gJ  ;  ces 
Indices,  diteralnes  a  partir  de  rigles  a  caractere  ’dictatorial*  laposMS  par  1'operateur  ou  le  Systeae 
Expert  qui  gere  le  processus  de  decision  presente  dans  la  suite,  ont  une  fonctlon  analogue  a  celle  des 
Indices  ;  1ls  caracterlsent  slapleaent  la  volonte  de  1 'utlllsateur  d'inflecbir  la  decision  finale  en 
pretant  une  attention  plus  grande  a  certelnes  Inforaatlons  qu'a  d'autres,  coapte  tenu  de  sa  connalssance 
personnel le  du  contexte  et  de  1 'evolution  de  celul-cl. 

c)  Oes  Indices  b1  de  pr£f£rence  *a  priori*  des  hypotheses  alses  en  Jeu  ;  ces  Indices 
tradulsent  la  volonte  de  1‘utlllsateur  de  trancher  arbitral reaent,  si  nHessaIre,  entre  plusleurs 
solutions  qui  seralent  ddclar^es  equlvatentes  par  1  'analyse  des  Inforaatlons  disponibles.  Cette 
possiblllte  repond  a  un  souci  degage  par  K.J.  Arrow  ;  ce1u1-c1  met  en  effet  en  Evidence  (1  et  2^ 
qu'aucune  regie  de  decision  autre  que  la  ’dictature*  n'est  satisfalsante  dans  1'absolu,  et  qu'en 
pratique  11  convient  d'adopter  un  compromis  judicleux  entre  la  rationallte,  le  caracUre  decisif  et 
1'egalltarlsae. 

Dans  le  cadre  du  probleae  tnlti  Id,  1 'analyse  des  Informations  dolt  done  rester  un  processus 
d'alde  3  la  decision  dont  11  convient  de  palller  les  llaltes  legitimes,  In  fine,  par  un  arbitraire 
ultlae  qui  tradult  la  politique  genSrale  de  I'utlHsateur  selon  la  situation  traltfe  (prudence  dans  les 
cholx,  determination  a  assurer  une  flnalltS  vltale...). 

Ces  trols  tjfpes  d'indice  procurent  done  des  degres  de  Hberte  supplemental  res  au  processus  d'alde 
a  la  decision  base  sur  la  fusion  des  seules  evaluations  eij  ;  11s  figurent  en  particuller  les  points 
d'entree  reserves  i  I'utlHsateur  ou  au  Syst^  Expert  responsable  de  sa  mise  en  oeuvre.  Us  ne  dolvent 
toutefols  en  aucun  cas  Itre  surabondants  par  rapport  a  la  connalssance  apportee  par  les  grandeurs  eij  . 

Notons  enfln  que  ces  Indices  o^j  ,  atj  et  bi  ,  alnsi  que  les  grandeurs  eji  ,  peuvent  i  priori 
prendre  leurs  valeurs  (ndlffereeaient  dans  I'un  des  trols  ensembles  sulvants  : 

-  1 'ensemble  blnaire  figurant  un  avis  tout-ou-rlen  present/absent,  bon/aauvals, 
vrai/faux...  .  Ce  sera  notanaent  le  cas,  pour  les  eij  ,  dans  une  structure  decentral  1  see  ou  chaque 
Infonaateur  prend  sa  decision  Independamment.  Le  processus  de  decision  propose  dans  la  suite  fournit 
alors  une  simple  table  de  verity  qui  etabllt  la  procedure  de  vote  i  adopter  dans  les  conditions  du 
problJae.  Toute  la  difficult*  de  la  decision  en  temps  reel  est  dans  ce  cas  reportSe  au  niveau  local  de 
chaque  Infonaateur  et  dolt  etre  r*sa1ue  par  la  Th*or1e  des  jeux  cooperatifs  (J1  =  J2  •  ...  >  JMl.  Les 
performances  obtenues  avec  une  telle  structure  sont  toutefols  necessalremcnt  mol  ns  bonnes  que  cel les 
d'une  decision  centrallsle,  lorsque  celle-cl  est  possible. 

-  r ensemble  des  rangs  ou  chaque  grandeur  prend  pour  valeur  son  ordre  de  priorit*.  Cette 
topologle  conduit  3  un  traltement  non  paraaetrique  des  Informations.  La  presence  d'ex-aequos  permet  Id 
de  prendre  en  compte  toutes  les  partitions  possibles  en  hypotheses  (ou  Informations)  equivalentes. 

-  1 'ensemble  des  reels,  la  grandeur  considered  3tant  alors  une  note  ou  un  polds  qui  permet  de 
prendre  en  coapte  une  aesure  de  1'ecart  separant  deux  valeurs  successlves.  II  en  est  par  exeaple  alnsi 
lorsque  les  grandeurs  considerees  r*su1tent  de  1'evaluatlon  d'une  distance  ou  d'une  probablllte,  en 
particuller  dans  le  cas  le  plus  general  oD  : 

(2)  e,j  =  PtHi/9jJ 

Ces  d(ff*rentes  topologies  peuvent  egalement  co-exister  dans  un  meae  processus  de  decision. 
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III)  mOCESSIIS  BE  DECISIM 

La  figure  2  repr^sente  le  processus  de  decision  siquentlel  qui  dicoule  loglqueaent  de  Vtpproche 
Introdulte  precideaaent.  11  consiste  en  prealer  lieu  I  {laborer  1es  grandeurs  caractirlstiques  Cfj  et 
les  Indices  cu) ,  a^j  etbi  .  Les  bypothises  HI  et  les  Inforsutlons  ^  qui  peuvent  etre  diflnltlveaent 
dcartles  par  ''affectation  d'un  Indlce  Blniaal.  )e  sont  d{s  que  possible  afin  d'evlter  tout  calcul 
Inutile,  notaaaent  au  niveau  de  1‘ilaboratlon  des  grandeurs  eij  ■  Cette  opdratlon  nous  raaSne  a  N 
hypothises  HI  possibles  (N^n)  et  M  Inforaatlons  disponibles  (M^a). 

Toutes  les  grandeurs  eij  et  les  Indices  oaj  et  Ati  restants  dolvent  ensulte  etre  haraoni s{s« tant 
du  point  de  vue  topologique  qu'en  ce  qui  conceme  1'lntervalle  de  variation,  afin  de  pouvolr  {tre 
confrontis.  La  transforaatlon  alse  en  oeuvre  dolt  toutefols  reprodutre  sans  distorsion  I'etaleaent 
relatif  des  valeurs  susceptibles  d'etre  observees,  cet  italeaent  {tant  Id  rSputS  parfalteaent 
repr{sentat1 f  de  la  caractSrlstlque  traltie  (eventualltl,  volonti,  •■•)  :  elle  dolt  done  conserver  toute 
relation  d'ordre  sur  I'enseable  des  valeurs  concemdes,  alnsi  que  toute  relation  d'ordre  entre  les 
accrol sseaents  sur  les  dliaents  de  cet  enseable  ;  elle  est  done  lindaire,  solt  : 

(3)  g] 

rintervalle  [0,  ij  dtant  arbitral reaent  retenu  pour  sa  co^atlbllite  laaedlate  avec  certalnes  notions 
utillsees  u1 tdri eureaent  (fonctlons  d'appartenance,  fonctlons  d'utlllte,  probabllltes,  ...). 
Typiqueaent,  elle  conduit  a  adopter  : 

(4)  CiJ  =  ~  et  (S)  Odj  =. 

ou 

,  (7)  ,  («) 

resultent  de  la  connalssance  des  caraetdristiques  et  des  Unites  physiques  des  grandeurs  traltdes,  de 
contraintes  operatlonnelles  (saturations,  .■•),  ou  d'une  ddteral natl on  enpirique  directe  a  partir  de 
valeurs  observdes.  Dans  1 'alternative  ou  ces  extrdaa  ne  sauralent  etre  dvaluds,  I'eaplol  de 
transfomatlons  non  lindalres  (exponentlelles,  ...)  dolt  etre  aanid  avec  discerneaent  coapte  tenu  des 
effets  qu'elles  Indulsent  dans  1e  processus.  Notons  que  I'eaplol  des  rangs  affranchit  de  ce  dileaae  dans 
tous  les  cas. 

II  convient  alors  de  rdallser  en  preaier  lieu  I'agrdgatlon  des  Indices  etdCyi  puisqu'lls 
reapllssent  la  aeae  fonctlon,  par  une  transformation  * 

(10)  = 

procurant  une  priorltd  globale  pour  chaque  Infonaatlon  disponible.  II  est  alnsi  possible  d'envisager  la 
fusion  Inter-Informations  des  grandeurs  tii  ,  en  prenant  en  coapte  pour  chacune  d'elle  sa  priorltd  KJ  : 
(U) 

La  recherche  du,  ou  des  aellleurs  coOts  Cl  alnsi  obtenus  procure  alors  la,  ou  les  hypothdses 
retenues  par  1 'analyse  des  Informations  disponibles. 

L'hypothdse  'optlmale*  HI**  est  finalement  cholsle  parml  les  No  hypotheses  ddgagdes  par  ce 
processus  (No  <  N),  dans  la  aesure  ou  celi  s'avere  ndeessaire,  grdee  au  classement  bi  fourni 
arbi tral rement  par  les  rdgles  'dlctatorlales*  conformement  a  la  phllosophle  ddgagde  au  paragraphe  II. 


Le  processus  ddtallle  Id  peut  egalement  dtre  ltdrd  de  fagon  Interactive  avec  1e  Systdme  Expert 
qui  le  gere,  et  qui  peut,  en  fonctlon  des  hypotheses  ddgagdes,  deaander  une  autre  analyse  avec  des  ids 
de  fusions,  des  priorltds  ou  des  topologies  diffdrentes. 

Un  module  d'allocatlon  de  ressources,  lul  aussi  gere  par  le  Systdme  Expert,  peut  enfin  ddfinir 
les  Informations  qu'11  convient  de  chercher  a  recuellllr  au  vu  des  evaluations  antdrieures.  Une 
recherche  et  une  discussion  de  techniques  appllcables  a  ce  module  dans  un  contexte  plus  global  ou  un 
nombre  Hmltd  de  moyens  d'analyse  dolvent  permettre  la  mellleure  dvaluatlon  simultande  d'un  certain 
nombre  de  situations,  sont  proposdes  dans  le  cadre  de  cet  expose. 

Dans  rimmedlat,  nous  allons  chercher  a  prdciser  la  transforaatlon  analytique  (11)  qui  assure  la 
fusion  des  {valuations  disponibles,  en  applicant  diffdrentes  thdorles  d'infdrence  au  probleme  alnsi 
ddfinl.  Notons  que  la  1o1  de  fusion  (10)  peut  etre  considdrde  coaae  une  application  trivlale  des 
formulations  qui  vont  ere  ddgagdes  pour  (11)  :  elle  ne  fera  done  pas  I'objet  d'une  investigation 
particullere. 


n)  LOIS  DC  FUSIOM 

Le  probleme  est  Id  d'diaborer  une  fonctlon  de  codt  Cl  dont  1 'optimisation  permette  de  ddtermlner 
l'hypothdse  HI  qui  maximise  le  vecteur  El  «  (  diix^isy  ••■y  E(n  )  (IZ),  d  coaposantes  dventuel lament 
incertalnes,  conformdment  au  processus  prdsentd  au  paragraphe  III.  La  1o1  de  fusion  cherchde  dolt  done 
fournir  une  relation  d'ordre  total  transitive  sur  les  hypothdses  en  compdtitlon  et  dtre  de  surcroft 
associative  par  rapport  aux  Informations  disponibles  (rdsultat  Inddpendant  de  1'ordre  de  fusion  des 
Informations),  ce  qui  exclut  d'emblde  un  certain  nombre  de  techniques  [3,  7,  8  en  particullerj .  Dans 
cette  optique  plusleurs  approches  sont  d  priori  envisagdes. 
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IV.l)  liraiaCE  MtESIEt 

Le  critire  optlaIsC  est  Id  : 

(13)  Ci= 

Li  rigle  de  B«ye$  founilt,  pour  des  (nfoi 


Li  rigle  de  B«ye$  founilt,  pour  des  inronMtIons  gj  Indipendantes  : 

C.=  P(Hi).rf^  P(H<J.  f^Plgj  /Hi] 

Dans  le  cadre  giniraf  aQ  : 

'15)  eijHPCaj/HO 

Cl  s'expriae,  pour  des  hypothises  £qu<probab1es  i  priori  : 

(16)  Ci= 

Le  denonlnateur  de  cette  expression  itant  Indipendant  de  1.  Cl  peut  s'ecrire,  si  Ton  Interprete 
parallileawnt  Oj  c(MM  la  fonctlon  d'utlllte  associie  a  1'entrople  de  cheque  teme  : 

(17)  Ci= 

11  est  toutefols  i  noter  que  cette  aethode  est  l^iropre  i  trailer  des  donnees  Incertalnes,  et 
qu'elle  exige  la  connalssance  exhaustive  de  tous  les  Elj  au  aoaent  de  la  decision. 

IV.2)  WlKllMI  D'EMTIMIHE 

Differentes  approches  peuvent  itre  envisagees  dans  ce  doaalne  Cl'l  ‘  mithode  la  plus 
frequeaaent  adoptee  utilise  une  aesure  de  la  quantite  aoyenne  d'lnforaatlon  disponihle  pour  cheque 
hypothese.  Les  Inforaatlons  gJ  itant  Independantes,  elle  conduit,  pour  une  aeae  difinitlon  (15)  des 
tii  qu'au  paragraphe  pricident,  a  retenir  : 

(18)  Ci  =  6ij  Log  £ij 

ou  01]  est  Interpreti  came  1a  fonctlon  d'uttllti  associie  a  cheque  Inforaateur.  Cette  mithode  ne^  se 
distingue  done  de  1'lnfirence  Bayislenne  que  par  une  pondiratlon  suppliaentalre  en  ti]  ;  ce  liger 
surcroft  de  coaplexlti  ne  peut  done  se  Justifler  que  par  des  perforaances  sufflsament  accrues,  les 
reaarques  faltes  alors  sur  les  conditions  d'eaplol  restant  valables  Id. 

IV.3)  CLASSBBIT  STOTISTIQUE  DlllECT 

Oiteralner  I'hypothise  HI  qui  aaxlalse  le  vecteur  El  -  (£ii|-";£|H  )  suppose  la  difinitlon  d'une 
relation  d'ordre  qui  pemette  de  coaparer  les  vecteurs  El  entre  eux.  Or,  si  1'on  ne  veut  pas 
particularlser  le  probliae  par  1’enptol  d’une  norae  spiciflque,  la  seule  relation  d'ordre  qu'11  est 
ralsonnable  d'adopter  adaet  qu'un  vecteur  est  supirleur  a  un  autre  si  toutes  leurs  coaposantes 
respectives  solvent  ce  classeaent,  soft  plus  priefseaent  : 

(19)  eoet  4=^  fc(i  >  £«  »  Vi  tt'L.nj 

Cette  relation  n'est  toutefols  pas  une  relation  d'ordre  total  des  lors  que  M  >  1,  et  la 
maximisation  de  El  peut  s'expriaer  de  deux  fagon  diffirentes,  qui  ne  sont  pas  equivalentes  :  soft 
chercher  a  avoir  un  minimum  de  vecteurs  supirleurs  au  vecteur  a  retenir,  soft  chercher  a  avoir  un 
maxiaum  de  vecteurs  Infirfeurs.  En  termes  probabllfstes,  cecf  s’exprfme  par  : 

et 

(21) 

SI  UiJ  disiqne  la  valeur  qu'est  susceptible  de  prendre  la  grandeur  Eij  ,  1 'indipendance  des 
coaposantes  Eijd'un  mime  vecteur  El  conduit  i  exprimer  (20)  et  (21)  respecti venent  par  : 

(24) 

Par  extension,  dans  le  cas  de  grandeurs  tii  Incertalnes,  les  conditions  (20)  et  (21)  dolvent  etre 
reaplles  pour  tous  les  vecteurs  El  dont  les  composantes  ill  sont  respecti veoent  comprises  dans  les 
Intervenes  t  tii’”'”  »  tij"""  J  ;  elles  dolvent  done  etre  diflnle-  pour  le  vecteur  El  le  plus 
contraignant  dans  chaque  cas,  a  savoir  tej  =  tij'"'"  pour  (20)  et  di]  =  pour  (21).  Les 

critires  Cis.  et  Cit  i  optimiser  selon  (22)  et  (23)  devlennent  dans  ces  conditions  : 


Ci4=  /^iir  P(u(j/Hf]au,j) 

Cit  =  j?  (I  au,j) 
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Ce$  deux  critires  encadrent  en  fatt  roptlaua  d'une  ‘quality  elnlaale  garantle*  (Cie)  et  d'une 
‘perforaance  aaxlBale  possible*  (  Cia.  ).  Ils  regroupent  done  a  eux  deux  1e  potentlel  nicessalre  et 
suffisant  pour  diflnlr  un  optlaua  au  sens  de  la  relation  d'ordre  (19).  Toutefols,  pour  rbpondre  au 
probldae  posS.II  convient  encore  de  les  fuslonner  en  un  critere  unique  Cl  a  saxlalser.  Afin 
d'hamonlser  les  effets  sur  Cl  des  dynanlques  de  chacun  des  criteres,  11  est  souhaltable  de  1u1  Inposer 
la  conservation  des  variations  relatives  des  deux  crltSres  Cia  et  Cit ,  solt,  coaipte  tenu  de  (22)  et  (23): 


(28) 

et 

(29) 


Ci  Cit 

«1Ci  d  Cia. 

TT  = 


L'integratlon  de  (28)  et  (29)  foumit  alnsi  pour  notre  probline  de  naxlmlsatlon  : 

(30)  Ci=  Cie/Cid 


Toutefols  les  expressions  (26)  et  (27)  sont  souvent  difficlles  a  etabllr  en  pratique,  par 
mlconnal stance  des  densites  PCuid/HcJ  •  Leur  application  au  cas  particuller  ou  la  densite 
PCHc). PCuij/HeJ  est  unifome  sur  [0,  ij  pemet  cependant  de  satisfaire  au  nleux  1e  cas  ou  les 
Infomatlons  gj  sont  blen  adaptees  au  probleoK  de  decision  pose,  produlsant  une  dispersion  maxlnale  des 
pour  1'ensenble  des  hypotheses  HI.  iqulprobables  a  priori.  Or  ce  cas  est  celul  qui  nous  Interesse 
puisque  1 ‘aptitude  de  cheque  Infomateurs  a  dlscrlnlner  les  differentes  hypotheses  est  *f11tre‘  par 
allleurs  (  ;  cf  11  et  III).  Notons  que  cette  slapllficatlon  est  plus  speclalement  Justiflee  avec 

1'enplal  des  rangs  pour  £■  j  ;  elle  conduit  dans  tous  les  cas  a  retentr  : 

(31)  Ci  =  'R. 


Par  allleurs,  une  diminution  du  facteur  de  quallte  Mj  dolt  se  traduire  par  suspicion  crolssante 
sur  revaluation  Sij  fournie,  et  done  par  une  augmentation  de  1 'Incertitude  sur  cette  grandeur.  Cette 
variation  dolt  en  outre  refleter  sans  distorslon  Vetaleoent  relatif  des  va1eurs0(j,  repute  parfaltement 
repr^sentatlf  du  doute  3  Introduire  ;  elle  est  done  lln^alre  : 

(32)  eijfoi — ►aj  eji"'" 


(33) 


£  . .  m«K  . 


d  -  «j(4- 


Notons  enfin  que  cette  technique  pennet,  central rement  aux  precedentes,  de  tralter  les 
applications  ou  I  1'lnstant  de  decision  toutes  les  evaluations  Eij  ne  sont  pas  encore  connues,  en 
affectant  aux  Inconnues  une  Incertitude  maxfmale  :  =  0  et  -1 


«.♦)  THIOIHE  DC  fEVinOCE 


Cette  technique,  dont  les  fondements  thioriques  ont  §te  posEs  par  Dempster  et  Shafer  (.12  a  uj  et 
dont  I'utmti  a  Ste  plus  receament  demontr£e  sur  des  applications  pratiques  (IS  i  18],  est  en  fait  une 
ginirallsatlon  de  I'lnffrence  Bayeslenne  au  traltement  des  donnees  Incertalnes.  Avant  d'en  produire 
('application  au  probleme  pos4  Id,  quelques  notions  de  base  sont  brlEvement  rappelees. 


IV.4.1)  WIESEIITATIOW  SUCClMCTt 

La  methode  suppose  N  hypotheses  exhaustives  HI  s'excluant  nutue) lament,  qui  constituent  un 
ensemble  E,  appele  ’cadre  de  dlscernement*.  Une  masse  m(N1)  est  attrlbuee  a  chaque  hypothese  pour 
quantifier  sa  propre  probablllte,  et  une  masse  m(E)  est  assignee  a  1'ensemble  £  pour  materlallser 
1'lncertltude  que  1'on  peut  avoir  a  designer  1'une  ou  1'autre  quelconque  des  hypotheses  HI  de  E.  Ces 
masses  dolvent  satisfaire  la  condition  : 

(34)  Z.  m(Hi) 

Oe  plus,  pour  tout  ensemble  ACE,  nous  avons  : 

(35) 

D'une  fagon  plus  ^nerale,  pour  tout  decoupage  de  E  en  sous-ensenbles  exclusifs  AJ  d'hypotheses,  deux 
notions  caract^rlsent  un  sous-ensemble  quelconque  A  de  C  : 


•  Le  support  de  A,  qui  repr«sente  la  probablllte  avec  laquelle  on  peut  affirmer  A  : 

(36)  S{ftJ=  m(flj) 

-  La  plausiblllte  de  A,  qui  repr6sente  la  probablllte  de  son  eventuallte,  e'est-a-dire  1a 
probablllte  avec  laquelle  on  ne  peut  affirmer  le  contraire  XdeA(AUX  =  E)  : 

(37)  P(H)=  =  d- S(ff} 

Sur  ces  bases,  la  thSorle  de  I'JvIdence  foumit  des  rbgles  d'infbrence  qui  penaettent  de  combiner 
des  Informations  provenant  de  sources  Indlpendantes.  Leur  prIncIpe  de  base  consiste,  pour  deux  sources 
produlsant  respectivement  des  Jeux  de  masses  {watmil.}  (dont  m*(6J  )  et  •{  ina(Bj)]  (dont  mife)  ) 

relativement  i  deux  decoupages  quelconques  de  E  en  sous-ensembles  exclusifs,  a  deduire  un  Jeu  de  masses 

ou  k  est  "I'lnconslstance"  de  la  fusion  : 

(39)  Z.  iTiaCfli)nit(8j) 

*1(161=  X 
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Cette  aSthode  autorise  en  particuller  la  fusion  de  M  sources  (M>  2),  1  ndipendament  de  1eur 
ordre  de  fusion,  ce  w1  satisfalt  1e  besoln  d'istdciativlte  pour  notre  probliaw.  E11e  presente  en  outre 
I'avantage  sur  1es  wthodes  pricidentes  de  peraettre  la  fusion  de  dicoupages  A1  et  BJ  diffirents  dans  1e 
cadre  de  discemeaent  C. 


IV.4.2)  /miCATiai  AU  WBtilg  post 

Pour  raaener  1e  probljae  itudli  au  foraallsae  de  la  ThMrIe  de  I'EvIdence,  les  grandeurs  6  ij 
dolvent  Stre  asslallies  B  une  aesure  de  vralseablance  des  differences  hypotheses  HI, pour  lesquelles  un 
support  et  une  ptauslbltltd  sont  alors  assocles  3  cheque  Inforaatlon  gj  ; 

(40)  SijCHi)=  nii,(Hi) 

II  convient  dans  ces  conditions  de  reallser  I'agregatlon  des  Sij  et^ij  de  fagon  a  obtenir  un 
support  S(H1)  et  une  plausiblllte  P(H1)  globaux  pour  chaque  hypothese  HI,  dont  11  faut  ensulte  assurer 
la  synthese  sous  la  forae  d'un  critere  unique  Cl  3  aaxialser. 


Blen  que  la  Theorle  de  I'EvIdence  reste  auette  au  niveau  de  cette  dernlere  synthese,  11  seable 
legitlae  dans  1e  cadre  du  probleaie  tralte  de  chercher  1'hypoth3se  la  plus  plausible  pour  laquelle, 
correlativeaent,  I'eventuallte  d'une  quelconque  autre  hfpothese  est  la  aolns  probable.  Ceci  revlent 


done,  en  vertue  des  notions  rappelees  au  paragraphe  precedent,  3  optimiser  conjolnteaent  : 

(«>  min  fCii) 

idCt.N]  ‘  ' 

<«'  T,[U]  t 


avec 

(44) 


et 


(45) 


C,i=  P(HiJ 


SI  de  surcrolt  on  veut  etablfr  un  critere  global  Cl  qui  conserve  la  d^^namlque  de  chacun  des 
criteres  Cti  etCit,  on  est  ainene»  Id  encore,  a  Imposer  I'ldentlte  des  variations  relatives  : 

(«)  dCi /Ci  =- dCit /Cii 

et 

(47)  dCi/Ci  •=  dC(t  /Cis. 

qui  conduit  par  Integration  3  : 

Cis  Cis  /Cji  =  P(Hi)/(d-  S(Hi)) 

La  determination  de  S(H1)  et  P(H1)  par  les  regies  d'tnf3rence  de  la  Th3or(e  de  I'EvIdence  est 
expllcitee  en  annexe. 

Elle  conduit  8  :  .  ,  M  ,  , . 

(«)  S(hi)s4-{]f^Cl-S(j(Hi)jJ/(ei  et(50)  PtHils 

(51)  fei  =  rf  pfjCHi) 4-fr  Cl- stHiU- f{  rP(j(Hi)- SfjCHi)] 

4rl  J'* 

L'expresslon  (48)  du  critere  Cl  affranchit  en  fait  du  calcul  de  kl,  et  1es  definitions  (40)  et 
(41)  de  Sij  et  Pij  procurent  finalement  : 

(52)  Ci=T? 

J*1 

II  est  3  remarquer  que  cette  1o1  de  fusion  est  la  meme  que  celle  obtenue  par  1e  classement 
statlstique  direct.  La  prise  en  compte  de  dolt  par  allleurs  se  faire  de  la  mime  fagon  par  (32)  et 
(33),  et  cela  pour  les  mimes  raisons.  Les  conditions  opiratlonnelles  d'emplol  sont  enfin  Identiques. 

IT.S)  THEOBIE  DCS  BBEItES  aOUS 

IV.S.1)  6EIBIW.ITES 

Afln  de  pemettre  la  prise  en  comtpe  de  I'impricis  dans  un  ralsonnement,  quelle  qu'en  solt  la 
nature,  L.A.  Zadeh  propose  de  definir  sur  un  ensemble  E  d'ellments  X  des  sous-ensembles  f1ous  A  a  I'alde 
d'une  fonctlon  d'appartenance  /*fl(X)  £l9  3  22]  :  ,  j(  _ 

r«  {  e  — co,n 

Un  lllment  X  est  d'autant  plus  considire  coane  un  lllment  de  1 'ensemble  A  que  sa  fonctlon  d'appartenance 
/n(X)  est  grande.  Les  valeurs  extrlmes  0  et  1  de  cette  fonctlon  correspondent  3  la  notion  blnaire 
d'appartenance  de  la  thiorle  "classlque"  des  ensembles.  La  thiorle  des  ensembles  flous  permet 
d'fntroduire,  par  rapport  3  celle-cl,  1e  fait  qu'un  lllment  appartlent  'plus  ou  molns'  a  un  ensemble  A, 
qu'un  Ivinement  est  plus  ou  molns  sur...  .  Un  ensemble  flou  est  done  un  ensemble  de  couples 
(X,  /*'A{X))  fe  E  X  to.  ij  .  Notons  toutefols  qu’une  fonctlon  d'appartenance  n'est  en  geniral  pas 
difinie  de  fagon  unique,  son  Interpritatlon  dIpendant  du  contexte. 
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Les  notions  classiqueraent  utlllsees  pour  les  ensembles  se  traduisent  id  par  des  relations  sur 
les  fonctfons  d'appartenance  ;  parmf  les  prindpales,  rappelons  : 

-  Tinclusion  :  flCB  t  &  9  4  A*#  CX) 

-  Vegallte  :  ^  g  yXte  f  s  Hb(X) 


La  comblnalson  convexe  C  de  A  et  6  est  par  allleurs  deflnie  par  : 

/^,(xj  =  (>i-ir)re(x)  ,  irfcto,4] 

Cette  theorle,  applicable  a  differents  domalnes,  apporte  deux  types  de  solution  aux  problemes  de 
decision  : 


I  a  cuni^  iCHicn  (,ar  I 

1  'union  : 

1 ' Intersection  : 


yXfeE, 

yXfeEt 


1)  Pour  un  ensemble  X  d'hypotheses  HI.  des  sous^ensembles  XGj  de  finalltes  GJ  a  satisfaire 
parmi  ces  hypotheses  et  des  sous-ensembles  XC(  d'hypoth^ses  resultant  de  contraintes  Cl,  l'ensend)1e  a 
retenir  est  : 


(53) 


U  =  (iJXGj)n(pXce) 


et  la  meflleure  d^fslon  Hi  a  prendre  est  donnee  par  : 
(54)  max  { 


ou.  done  :  ryj,(Hi)=mm  (  rxs/H.),r)C£j(Hi)} 
Nous  designerons  dans  la  suite  cette  technique  par  Vintitule  “Decision  par  Finalite  Floue"  (DFF). 


2)  Dans  1e  meme  contexte  que  cl-dessus,  une  decision  ponderee  conduit  a  retenir  une 
comblnalson  convexe  des  ensembles  Xqj  et  Xct  *  decision  HI  est  alors  designee  par  : 

(55)  max  ou :  /xd(h,)= 

t  avec  :  £  /9j  +  Kj  =  -1 

Cette  technique  sera  iabeDee,  dans  la  suite  :  ”  Decision  Convexe  Floue"  (DCF). 


IV. 5.2)  tfPLlCATlOII  AU  PHOBLEIC  POSE 


Dans  notre  cas,  11  convient  de  satisfaire  un  certain  nombre  de  finalltes  que  sont  les  avis  donnes 
par  les  differents  Informateurs.  Un  ensemble  Xg/  est  done  pour  nous  1 'ensemble  des  hypotheses  retenues 
par  I'informateur  gj  comme  etant  les  plus  satisfaisantes.  De  fagon  limedlate,  la  fonction  d'appartenance 
d'une  hypothese  Hi  a  1 'ensemble  Xaj  est  dfrectement  donnee  par  la  grandeur  £(j  qui  rempllt  toutes  les 
conditions  requises  pour  cela.  ' 


En  I'absence  de  contraintes,  la  DFF  conduit  a  retenir  I'lntersectlon  des  avis  emis  par  les 
differents  informateurs,  et  a  designer  1 'hypothese  Hi  qui  satisfait,  d'apres  (54)  ; 

(56)  maxfC,}  ,  C,  =  min  {tijj 

I  «l 

Dans  le  cas  de  grandeurs  6»i  Incertalnes,  les  valeurs  comprises  entre  et 

doivent  etre  considerees  comme  autant  d'avis  possibles  a  satisfaire  ;  Texpression  (56)  devfent  alors  : 

(571  max  I  Ci)  ,  Ci  =  mjn 

Paral leleroent,  la  DCF  conduit  dans  le  meme  contexte,  et  pour  des  avis  equipollents,  a  retenir 
1 'hypothese  Hi  designee  par  (55)  :  ^ 

(58)  r^FlKfC,]  ,  Ci  =  ^ 

L'indice  de  quallte  fl(j  est  Id  aussl  suppose  integre  dans  Vintervalle  d'lncertltude  par  (32)  et 
(33).  Notons  qu'en  ce  qui  concerne  (58)  une  autre  attitude  pourralt  consister  a  ne  pas  integrer  0(j  dans 
Vintervalle  d'lncertltude  et  a  T'utlliser  coime  coefficient  de  la  comblnalson  convexe  ;  les  deux 
attitudes  conduisent  toutefois  rlgoureusement  au  meme  resultat. 

V)  APPLICATIOW  A  LA  CIASSIFICATIOM  HULTl-WTEURS  DE  CIBIES 

V.l)  PRESEWTATIOM  GEIfERALE 

Conformement  a  la  figure  3,  Velaboration  des  grandeurs  ,  qui  representent  les  polds  affectes 
a  chacune  des  classes  possibles  1  par  chacun  des  capteurs  j,  fait  Vobjet  d'un  pre-traltement  propre  I 
chaque  capteur,  decomposable  en  deux  etapes  :  la  premiere  consiste  a  extraire,  a  partir  des  slgnaux  ou 
des  Images  releves  par  le  capteur.  les  grandeurs  caracterlstiques  d**  Vobjet  observe  qui  sont 

Invarlantes  aux  conditions  de  mesure.  Les  valeurs  obtenues  sont  alors  comparees  aux  grandeurs  de  meme 
nature  apprises  au  prealable  sur  chaque  type  de  cible  possible,  a  Valde  de  discrimlnateurs  propres  a 
evaluer  leur  degre  de  similitude  avec  chacun  de  ces  apprentlssages,  la  grandeur  tij  cherchee  etant 
directement  representative  de  cette  simivtude.  Typiquement,  ce  prc*traitement  peut  etre  realise  par 
fiJtrage  Inverse  ou  par  flltrage  adapte  de  slgnaux  Invariants,  ou  chaque  flltre  est  adapte  a  une  classe 
de  cible  ;  dans  le  cas  d'lmages,  ce  peut  etre  la  comparalson  par  une  distance  statlstique  de  moments,  ou 
la  correlation  de  contours,  de  squelettes,  ou  de  textures  pour  chaque  classe  possible. 
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Les  grandeurs  Sij  obtenues  sent  a1ors  fusionnees  selon  1e  processus  presente  precedeament,  qui 
pemet  la  prise  en  coopte  du  contexte,  de  I'environnenent,  et  de  touts  connaissance  ext^rfeure  ou 
prealable  pour  conduire  au  choix  de  la  classe  la  plus  probable. 

La  plupart  des  mStbodes  abord^s  pemettant  en  outre  la  prise  en  conpte  de  grandeurs  dij 
Incertalnes.  11  est  Id  propose  d'utlllser  un  iventuel  apprentl ssage  de  la  natrlce  de  confusion  de 
cheque  capteur  pour  detemlner  1 ‘Incertitude  llee  a  cheque  evaluation  ejj  .  Le  terme  general  d'une 
telle  matrice,  assoclee  au  capteur  J,  est  en  effet  representatif  de  la  probablllte  qu'a  ce  capteur  de 
reconnaltre  la  cible  Ic  lorsque  la  dble  i  lui  est  presentee  : 

(59)  P,j{  =  P  (  Cjy  =  max  j  /c.blfc  i J 

Son  terme  diagonal  figure  done  directenent  le  degre  d'aptitude  de  la  grandeur  6ij  a  bien 
reconnaltre  la  cible  1  ;  toute  diminution  de  sa  part  dolt  par  consequent  se  traduire  par  une  suspicion 
croissante  sur  1 'evalutatlon  eij  fournie,  e'est-a-dire  par  une  augmentation  de  V incertitude  sur  cqtte 
grandeur.  Cette  variation  doit  en  outre  refleter  sans  distorsion  Tetalement  relatif  des  , 

repute  parfaitement  representatif  du  doute  a  Introduire  ;  elle  est  done  lineaire  : 

(60)  feij""'*  = 

=  «jmox-Prf^‘fej„ax-eij) 

Notons  qu'en  toute  rigueur  cette  fagon  de  proceder  est  adaptee  a  un  choix  correct  des 
dlscrimlnateurs.  qui  garantit  aux  termes  diagonaux  de  la  matrice  de  confusion  d'etre  maximaux  pour 
I'hypothese  testee  ;  si  tel  n'etalt  pas  le  cas,  11  convlendrait  d'affecter  a  revaluation  de 
I'hypothese  Hi  le  resultat  de  I'evalutation  C^j  qui  presente  la  plus  forte  probablllte  de 

reconnaissance  de  cette  hypothese  HI,  et  correlativement  d'utlllser  la  probablllte  pour 

1 'elaboration  de  son  incertitude.  II  faut  toutefois  etre  consclent  qu'alors  peuvent  naTtre  des  conflits 
entre  hypotheses,  qui  ne  pourront  etre  resolus  que  par  un  apport  exterieur  d' Information  ou  de  consignes 
“dicta torlales". 

Va2)  OEHPLE  DE  MSE  EN  OEUVRE.  COWPARAISON  DES  DIFFEREMTIS  SOLUTIOIIS 

A  des  fins  de  pragmatisme,  les  differentes  solutions  degagees  au  IV  sont  appliquees  dans  le  cas 
d'un  scenario  simple  de  classification  de  3  cibles  a  I'alde  de  2  capteurs,  Imagine  pour  1 'occasion.  Les 
matrices  de  confusion  de  chacun  des  capteurs  sont  donnees  en  figure  4.  II  est  a  noter  1 'aptitude  du 
capteur  1  a  reconnaltre  la  cible  I,  mais  son  Incompetence  en  ce  qui  conceme  les  cibles  2  et  3  ; 
Inversement  le  capteur  2  montre  une  bonne  aptitude  pour  la  cible  3,  mais  une  certaine  medlocrite  pour 
les  cibles  1  et  2. 

La  figure  5  presente  une  sequence  d'evaluatlons  £0  obtenue  a  I'aide  des  deux  capteurs, 
successivement  sur  les  trols  cibles.  Ces  valeurs  ont  §te  selectionnees  en  accord  avec  les  matrices  de 
confusion  presentees  plus  haut  :  on  peut  en  particulier  verifier  qu'en  fonctionnement  mono-capteur  le 
capteur  1  ne  reconnatt  que  la  cible  1  et  le  capteur  2  ne  reconnait  que  1a  cible  3,  les  bonnes 
reconnaissances  Itant  entourees  en  trait  plein  et  les  fausses  detections  en  trait  discontinu. 

La  figure  6  presente  les  resultats  obtenus  pour  les  trois  memes  essais  en  fonctionnement 
multi -capteurs,  a  I'alde  de  I'lnference  Bayeslenne  (IB),  du  Maximum  d'Entropie  (ME),  et,  a  titre  de 
reference,  de  la  Theorie  de  1‘Evldence  (DS)  appllquee  aux  donnees  certaines  (  s  ). 

Les  trols  methodes  pentiettent  de  conserver,  dans  ce  cas,  toutes  les  competences  individuelles  en 
reconnaissant  les  cibles  I  et  3. 

En  revanche,  elles  restent  toutes  impulssantes  a  reconnaltre  la  cible  2  par  deduction.  Si 

cependant  on  utilise  comme  critere  secondaire  de  comparaison  des  trois  methodes  I'ecart  relatif  entre 

les  deux  mellleures  valeurs  du  cout  Cl  pour  les  essais  ayant  conduit  a  une  bonne  reconnaissance,  la 
palme  de  la  meilleure  robustesse  revlent  a  la  Theorie  de  1 'Evidence. 

La  figure  7  montre  les  resultats  obtenus  dans  les  memes  conditions  a  I'aide  de  la  Theorie  de 
I'EvIdence  (DS),  de  la  Decision  par  Flnallte  Floue  (DFF)  et  de  la  Decision  Convexe  Floue  (DCF), 

lorsqu'on  utilise  des  donnees  Incertalnes  etablles  a  I'alde  de  (60)  a  partir  des  E-fj  du  tableau  de  la 

figure  5  et  des  matrices  de  confusion  de  la  figure  4.  La  mise  en  oeuvre  de  donnees  incertalnes  permet 
maintenant  de  reconnaltre  les  trois  cibles.  A  noter  egalement  sur  1'exemple  traite  le  mauvais 
comportement  de  la  DFF,  et  toujours  la  plus  grande  robustesse  de  la  Theorie  de  I'EvIdence,  au  sens  du 
critere  secondaire  defini  plus  haut. 

Une  etude  statlstique  du  comport^nt  de  ces  methodes  en  fonctlon  de  la  quallte  de  chacun  des 
capteurs  est  lllustree  par  les  figures  8  et  9  dans  le  cas  de  2  cibles  et  2  capteurs.  Chaque  resultat 
fait  I'objet  de  1000  tirages  aleatolres  pes  selon  une  densite  uniforme  dont  les  bornes  assurent 

les  differents  taux  de  reconnaissance  rappel^s  en  regard  pour  chaque  situation  testee.  La  figure  8 
pr^sente  les  taux  de  reconnaissance  moyens  obtenus  par  les  trols  methodes  retenues  plus  haut  pour  le 
traiteoent  des  donnees  certaines,  et  la  figure  9  montre  les  m&nes  estimations  pour  les  trois  methodes  de 
traitement  des  donnees  Incertalnes.  Dans  chaque  cas  les  performances  correspondantes  obtenues  a  I'alde 
du  mellleur  capteur  seul  et  du  f?K>1ns  bon  capteur  seul  sont  rappel^s  a  titre  de  reference  :  un 
fonctionnement  multl-capteurs  etant  en  general  choisi  pour  la  bonne  complementarite  des  differents 
capteurs,  11  est  a  priori  souhaltable  qu'11  garantisse  un  fonctionnement  au  molns  aussi  bon  que  le 
mellleur  des  capteurs  pris  individuellement. 
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L'attentlon  du  lecteur  dolt  cependant  Stre  attiree  sur.  1e  fait  que  les  cas  de  aauvais 
fonctlonneiaent  cholsls  1c<  sent  particulfercaent  draconlens  (  Pi|d  •  0,25)  par  rapport  a  un  aauvais 
fonctlooneaent  classiqueaent  observi  on  reconnaissance,  qui  conduit  plutdt  i  1' 1 ndl f ference 
(  -  0,5).  Ms  presentent  toutefols  la  particularity  de  blen  aettre  en  yvidence  I'avantage 

et  la  robustesse  de  la  technique  de  fusion  elaboree  a  partir  de  la  Thiorlede  1 'Evidence,  alnsi  que  1e 
blen  fonde  de  cette  fafon  de  prendre  en  coopte  un  apprentlssage  prealable  des  aatrices  de  confusion  des 
diffyrents  capteurs  sous  forae  de  donnies  Incertalnes.  Le  rysuHat  obtenu  par  cette  technique  est  par 
allleurs  tout-a-falt  satisfalsant  en  regard  des  perforaances  du  aellleur  des  capteurs,  pris 
1nd1v1due11eaent.  II  est  en  revanche  a  deplorer  un  aauvais  coaporteaient  de  la  OFF,  blen  que  ses 
blenfalts  alent  pu  etre  apprydes  par  allleurs  dans  des  applications  trds  precises,  et  qui  est 
vralseablableaent  du  a  la  prise  en  coepte  quelque  peu  soaaiaire  et  expedltlve  de  I'lnforaatlon  disponible 
qu'elle  est  aaenye  a  opyrer  dans  ce  contexte. 

VI)  PlMCEllMg  B'/UXOMTIMI  BE  gESSOUIgS 

Le  probiyae  abordy  Id  est  la  recherche  de  la  aellleure  attribution  de  M  aoyens  d'analyse  J  au 
tralteaent  de  L  situations  1  a  analyser  slnuHaneaent,  a  partir  d'une  connalssance  prealable  de  cheque 
situation,  afin  d'etre  en  aesure  de  fournir  la  aellleure  evaluation  sur  I'enseable  des  situations.  La 
connalssance  prealable  utlllsee  peut  provenir  d'lnforaatlons  extyrieures  au  systeae,  ou  d'une  prealere 
analyse  Inopinee  par  des  Inforaatlons  non  necessalreaent  appropriyes. 

Les  donnees  utiles  sont  de  trols  types,  deflnls  de  la  faqon  sulvante  : 

-  Li|*  =  rutmte  “a  priori"  de  declarer  I'hypothese  HI  pour  la  situation  1  (O^Llj^^.  1)  ; 
11  est  par  exeaple  plus  urgent  de  reconnattre  un  hostile  proche,  qu'une  c1b1e  lointalne  ou  peu 
dange reuse. 

-  Pi*  -  le  polds,  eventuellement  Incertain,  affecte  presenteaent  a  1 'eventual Ite  HI  pour  la 
situation  1  (0<  P(‘4  1). 

-  °  la  probability,  pour  1 ‘Inforaateur  J,  de  declarer  I'hypothese  Hk  en  presence  de 
I'hypothese  HI  j  e'est  done  le  degre  d‘apt1tude  de  la  declaration. Hk  a  discrialner  I'hypothese  HI,  pour 
le  capteur  J.  Typiqueaent,  pour  un  probleae  de  reconnaissance,  est  le  terae  general  de  la  aatrice  de 
confusion,  deja  presentee  au  V. 

Deux  approches  vont  aalntenant  etre  proposyes  pour  resoudre  ce  probleae  une  approche 
“classique"  par  Inference  Bayeslenne,  qui  nous  servira  de  ryfyrence,  puls  une  technique  utlHsant  la 
fusion  de  donnees  Incertalnes,  Issue  de  1 'etude  qui  precede.  Ces  deux  aethodes  seront  coaparees  sur  la 
base  d'un  scenario  slaple  de  reconnaissance  de  cibles. 


VI.l)  SOLIfriflll  MTESIOIff 


les  Pi* 
(61) 


Dans  cette  approche,  toutes  les  donnees  prealables  sont  nycessalreaent  des  donnbes  "certalnes”  et 
sont  supposes  normal Isys  : 
rL  P,tr  -1 


II  est  alors  possible  de  definir  la  Fonctlon  d'Utlllte  presente  de  la  situation  1  : 

(62)  •n«F(PiSUjn 

puls  sa  Function  d'Utlllte  moyenne,  pour  toutes  les  declarations  Hk  possibles,  si  on  lul  affectalt 
r  Inforaateur  j  ■  ^J  .1  _  ^  pfdeclorerHfcJ.mox  {P[Hi/Hfcdeclorey  .Ui'j 

qul^devlent,  grace  a  la  regie  de  Bayes  :  ^  j  P,  *.Ui*} 

On  peut  alnsi  determiner  la  Fonctlon  d'Utlllte  Marginale  llee  a  I'assoclatlon  de  1 'Inforaateur  j 
et  de  la  situation  1:  /Mjf-U'*-U* 


II  convient  alors  de  comparer  les  H  comblnalsons  h  possibles  entre  les  M  Informateurs  j  et  les  L 
situations  1  =  h(j)  sur  la  base  de  leur  aellleure  Fonctlon  d'Utlllte  Marginale  moyenne,  afin  de  designer 
la  aellleure  d'entre  elles  :  ,  er.i 

(65)  man  ^  Cji  }  avec  :  C^  =  ^  flUj 

Cette  methode  presente  toutefols  la  particularity  de  ne  lalsser  autune  place  a  I'lncertltude 
(notaament  sur  les  Pi^  et  Dj'  ),  de  supposer  lapHclteaent  une  Inference  Bayeslenne,  et  de 
n'optimiser  qu'une  Fonctlon  d'Utlllte  moyenne,  ce  qui  ne  sont  pas  les  gages  des  mellleures  perforaances, 
comae  nous  avons  dyja  pu  le  constater.  La  methode  qui  suit  propose  un  reaede  a  ces  lacunes. 
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VI.Z)  SOLUTIMI  HMWBtt 


Pour  rSpondre  aux  dlffirents  soucis  dijagis  par  la  aatltode  precidente,  nous  pouvons  dSfInIr  une 
Fonctlon  d‘Ut111t£  prisente  de  la  situation  1  de  fafon  Incertalne  : 
lUo*"”"*  J  f'tmM.Ui*”'"  J 

*®®’  I  =  max 

De  aSne,  la  Function  d'Utlllti  'a  postirlorl"  d'assocler  I'lnfonnateur  j  a  1a  situation  1  peut 
itre  bornSe  par  :  i  r’jjj'’  {  max  (pirxUi*"""]} 

Jt  '  =  "t*  {  i'"'*’)} 

ou  r^suHe  de  la  fusion  des  grandeurs  Pjf  et  ;  si  Ton  retlent  pour  cette  fusion  la  r^gle 
pr^cedennent  ^labor^  3  partfr  de  )a  Theorle  de  ) 'Evidence  ou  du  classeaient  statlstique  direct,  et  ceci 
en  raison  de  ses  proprl£t$s  en  accord  avec  le  contexte  traltE,  11  vient  1a  detemlnatlon  de  : 

(68)  J..emax  ^ 

qu‘1I  convlent  de  ranener  dans  I'lnterxalle  ^0.  Ijpar  la  transformation  Inverse  : 

(69) 

La  Fonctlon  d'Utlllte  Marginale  de  I'informateur  j  pour  la  situation  1  peut  flnalement  etre 
encadree,  dans  rintervalle  fO,  Ij,  par  : 

I  I  ‘ 


_ -  _ - _  . .  ^  par  : 

(  A  Uj- '  =  i  U j  -  L)of'™»4- 1 )  /  2- 

L'elaboratlon  du  critere  Ch  a  optimiser  pour  determiner  1a  mellleure  des  H  combinalsons  h 
possibles  entre  les  H  Infonsateurs  j  et  les  L  situations  1  -  h(J),  peut  alors  se  faire  par  la  meme 
technique  d'inference,  pour  les  nemes  raisons  : 


Cft=  7:i 


Remarquons  que,  quelle  que  solt  la  methode  utlllsee,  1 'association  I  >  h(J)  ne  peut  etre 
bijective  que  pour  1.  -  N.  Dans  tous  les  cas,  les  situations  non  analysees  par  la  conblnalson  h  ne  sent 
Vobjet  d'aucune  modification  de  1eur  fonctlon  d'utlllte,  et  ne  sont  par  consequent  pas  prises  en  cwte 
par  (71)  ou  par  (6S)(0n  peut  verifier  que  leur  prise  en  compte  pour  un  Infomateur  fictif  tel  quelJj‘»U, 
ne  modifle  1e  rAsultat  dans  aucun  des  cas)  ;  Inversement,  une  situation  1  pour  laquelle  une  conblnalson 
b  privolt  une  analyse  conjointe  par  plusleurs  Informateurs  dolt  voir  les  effets  de  ceux-cl  se  cumuler, 
ce  qui  est  Impllcltement  pris  en  compte,  aussi  blen  par  (71)  que  par  (65),  Motons  enfin  qu'une  gestlon 
Judicleuse  des  combinalsons  d'interet  par  1e  systeme  expert  dolt  limiter  1 'aspect  comblnatolre  des 
calculs  i  effectuer,  quelle  que  solt  la  solution  adoptee. 

VI.3I  CaWPWUUSOM  DES  DEUX  SOtUTlOKS  SUR  UM  EXENPU 


Reprenons  1'exemp1e  de  classification  de  trols  cibles  a  I'alde  de  deux  capteurs  deja  utilise  au 
y.2,  avec  les  menes  valeurs  nunArlques.  Supposons  deux  situations  a  analyser,  dont  chacune  d'elle  a  deja 
fait  I'objet  d'une  Investigation  de  la  part  d'un  des  capteurs  :  par  convention,  designons  par  1  =  1  la 
situation  deja  analysee  par  le  capteur  1  et  par  1*2  cel1e  deja  analysle  par  le  capteur  2,  quelle  que 
solt,  en  fait,  1 'Identity  de  la  cible  mise  en  jeu  dans  cbaque  cas.  Supposons  par  allleurs  que  nous  avons 
deux  possibllltes  d'assoclatlons  : 


-  h  «  1,  rien  ne  change,  cheque  capteur  continuant  a  scruter  la  meme  situation. 

-  h  =  2,  les  capteurs  sont  Inverses,  le  capteur  1  devant  maintenant  analyser  la  situation  2 
et  le  capteur  2  la  situation  1. 

Par  souci  de  clarte,  nous  retlendrons  enfin  :  ^  I),*""' -  i  ,  yijt. 

Dans  ce  contexte,  9  scenarios  peuvent  etre  tes^s,  correspondant  chacun  a  un  couple  de  cibles 
different  pour  le  couple  de  situations  analysees.  Les  sont  dans  ces  conditions  directement  les  £ij 
de  la  figure  5,  pris  pour  1 'association  cible-  capteur  supposee  reallsSe.  Les  Pi*"’'"  et  p,'"’®*  sont 
blen  sur  les  £(]•"■•  et  Cij'"**  deja  elaborAs  au  V.2  a  partir  des  tableaux  des  figures  4  et  5,  pris 
dans  les  memes  conditions  d'assoclatlon.  Les  sont  enfin  directement  ceux  donnAs  par  la  figure  4. 

La  figure  10  rassemble  les  coDts  Ch  obtenus  pour  chaque  mAthode  et  cheque  scenario,  une  situation 
etant  diflnle  par  le  numSro  1  de  la  cible  qul  la  constitue.  Le  comporteeent  du  systeme  aprJs  fusion,  si 
Ton  joualt  1 ‘association  h  prAconisAe,  etant  connu  par  I'analyse  du  V.2,  11  est  possible  d'entourer  en 
trait  continu  les  bonnes  propositions  et  d'un  trait  discontinu  les  maJvalses.  La  comptablllsatlon  des 
bonnes  decisions  met  alors  en  evidence  I'avantage  de  la  methode  proposAe  sur  cet  example,  surtout  si 
I'on  note  qu'elle  n'exlge  aucune  connalssance  supplementaire  Id,  Us  PfR**  etant  de  toute  fagon 
nAcessal res . 


vii)  caci-iisioii 


tin  processus  d'alde  a  la  dicislon  a  iti  proposi,  qu1  autorise  1'eaiplol  de  differentes  techniques, 
aussi  blen  pour  la  fusion  des  donnies  autll-lnforaateurs,  que  pour  I'Allocatlon  de  Ressources  en  teaps 
rdel,  c'est-a-dire  1 'affectation  d'lnfonaateurs  a  I'analyse  slaultande  de  plusleurs  situations. 
L'appllcatlon  de  ces  techniques  a  des  scenarios  sliples  de  classification  de  cibles  fait  apparaftre, 
pour  chaque  fonctlon,  un  net  avantage  de  la  aSthode  £1aboree  8  partir  de  la  Th8or1e  de  1 'Evidence  de 
Deopster  -  Shafer  et  confortee  par  une  approche  de  classeaent  statlstique  direct.  Cette  aethode  tire 
Tessentlel  de  sa  force  du  tralteaent  de  grandeurs  Incertalnes,  qui  peraet  la  prise  en  coaipte  d'une 
connalssance  prdalable  sur  la  qualltd  des  diffdrentes  evaluations  fournles  par  les  Inforaateurs.  SI  done 
certalnes  aithodes  offrant  les  aeaes  possibllltes,  notaaaient  ce11es  Issues  de  1a  th£or1e  des  enseables 
flous,  dolvent  eventuelleaent  etre  reconsi derees  dans  1e  cadre  de  conditions  particulldres 
d'appllcatlon,  1e  potentlel  de  la  aethode  proposee  a  partir  de  la  Thdorle  de  I'EvIdence  par  rapport  aux 
approches  plus  traditlonnelles  seable  un  acquis  Indlscutable,  mis  en  Evidence  par  les  resultats  obtenus. 


Cette  deteralnatlon  resuite  de  1'agregatlon  de  N  x  M,  sources  de  connalssance  caracterlsant  N 
hypotheses  (d'indice  1)  a  partir  de  H  Inforaateurs  (d'indice  J)  ;  ces  sources  sont  decrites,  dans  1e 
cadre  de  la  Theorle  de  I'EvIdence,  par  ; 

fmij  CHi)  =  Sij"'"  = 

•"(j  (Hi)  =  d-  =  d  - ftilHi) 

_  mij  ce)  =  ty”"- feij'"'"  = 

ou  HI  represente  1e  congileaent  de  H1  dans  E. 

L'agregatlon  envisagee  dolt  etre  aenee  en  deux  temps,  pour  ten1r  coapte  des  particularises  du 
probleme  : 

1)  Agrdgatlon  Inter-Inforaateurs  pour  les  concernant  une  meme  hypothese  HI. 

2)  Agrdgatlon  des  Evaluations  obtenues  directement  pour  chacune  des  hypotheses  HI,  afin 
d'obtenlr  1 'Evaluation  globale  de  chacune  d'elle. 

n  AGREOATIOH  INTER-IHFORMATEURS 


Cette  agrEgatlon  concerne  M  sources  de  connalssance  Independantes  qui  dEcrIvent  1e  cadre  de 
dlscernement  £  par  les  memes  sous-ensembles  d'hypothEses  : 

<  i"ij  (Ml)>  tniJCHiif  ti.)  lit>> 

Les  regies  d'lnference  de  la  ThEorle  de  I'EvIdence  procurent  dans  ce  cas  : 

(2)  j  T?  Cmij(Hi)s-nuj(E)]  -  /6i 

(3)  mi(E)  = 

(4)  J  7T  ^  mijCs.)!  /^, 

K  J=-t 

Sachant  que  : 

(7)  P((Hi)=  mi(Hi)  +  m>(E) 


(2),  (3)  et  (1)  procurent  : 
(8) 


ou  k1  s'EcrIt  d'aprEs  (6)  et  (1)  : 

(9)  »,=  §  Pij(Hi)  tT?  Ci-  S,j(Hi)]-  JT  SijCH.JJ 

J-*  j-1  Jr'i 

O'autre  part,  sachant  que,  par  definition  : 

(10)  Si(Hi)=  d-  P,(H,)  =  -l-Cm4H;j+m,fE)J 

(4),  (3)  et  (I)  amenent  =  S.(h.)=  d- S.i(H0])/Rr 
OU  k1  est  toujours  donne  par  (9) 


i 

A. 

i 
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II)  ASRESATIOW  IMTER-HrPOTHESCS 


Cette  itepe  prend  aelntenent  en  coapte  N  sources  de  connsisssnce  qui  dScrlvent  1e  cadre  de 
discemeaent  E  s  ( Hh}  par  des  sous-enseables  d'hypoth^es  dfffdrents  ;  cheque  source  reste 
cependant  de  type  oinaire  entre  une  proposition  HI  et  sa  negation  HI  : 

matfla)*  inaiej  > 

<  nil  (HO  f  milil'i  )tei)(E)  > 

<  mn(HM)s  niHCflH)«mHCe)> 

Ces  Basses  se  didulsent  iBn^dlateaent  des  grandeurs  SKHI)  et  P1(H1)  ditemln^s  a  I'itape 
prSc6dente  par  :  ,  SitH.^ 

(12)  <  mitH.)  =  -l-P.tHi) 

(  iniCC)  =  Si(Hi) 


► 


11  est  de  plus  possible  d'dvaluer  1e  support  et  la  plausibility  accordis  i  une  hypothyse  HI  par 
une  source  de  connalssance  volsine  1  (1  ^  1)  pour  N  >  2  : 

(13)  JSt(H0=O 

(  Pf  CHi)=  mt(Ht) 


Conpte  tenu  de  la  dependence  des  dlffirentes  evaluations  fournles  par  un  mene  Informateur,  et  du 
fait  que  les  N  sources  de  connalssance  tralties  Id  risultent  de  1'agregatlon  des  M  menes  Infonnatlons 
gj,  ces  sources  ne  sont  pas  Independantes.  Le  support  global  et  la  plausibility  globale  de  cheque 
tiypothyse  HI  sont  done  obtenus  par  :  ,  ,  , 

(S(Hj  =  man  fSfCHOl 

(U,  t  t  n 

ce  qui  nous  conduit  3  : 

(15)  S(H1)-S1(H1) 


Oe  plus,  les  masses inj(Hi')  et iriECHf)  resul tent  de  ('Inference  des  nemes  Infomateurs,  une  yia^ratlon 


correcte  des  masses  1n1t1a1esmij(H{l 
et  par  consyquent,  d'aprys  (12),  (13) 

(16)  P(H1)  •  PKHI) 

flnalement,  si  on  Intdgre  les  rysultats  (8)  et  (11) 
(1^1  S(H0= 

ou  kl  est  toujours  ddflnl  par  (9) 


garantit  mi(Hj)  >  m[(H(),gr^l,  puisque 
et  (14)  ; 


Ht  C  Hi 


de  la  premiyre  ytape,  (15)  et  (16)  devlennent 
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Abstract 

This  paper  addreeses  the  role  and  the  design  of  a  Software  Engineering  Data 
Base  in  an  Advanced  Support  Environment.  A  first  introduction  recalls  the 
evolution  of  the  File  Management  System,  from  the  earlier  beginning  of  the 
Operating  System  up  to  now  where  sophisticated  ones  are  available.  It  is  shown 
why  the  classical  File  Management  System  is  not  sufficient  in  the  context  of 
the  software  development  process.  Thus  Object  Management  Systems  are  now 
under  consideration.  We  examine  their  role  and  for  some  Software  Engineering 
Environments  we  exhibit  what  are  their  main  functionalities.  But  because  they 
are  independent  on  the  languages  they  support,  they  work  at  the  macroscopic 
semantics  of  the  manipulated  objects.  Furthermore,  they  only  concern  static 
(or  predefined)  properties  of  the  development  process.  Thus  there  is  great  need 
for  a  Software  Engineering  Data  Base  in  which  more  semantics  can  be  taken 
into  account,  especially  at  the  level  of  the  object  description.  This  will  allow  to 
guarantee  the  consistency  of  the  information  stored  in  a  Project  Tata  Base. 

This  project  is  supported  by  the  ESPRIT  Programme  (#P510  TooWse)  and  ONERA. 


Keywords:  File  Management  System,  Object  Management  System,  Project  Data  Base,  Soft¬ 
ware  Engineering  Data  Base. 

Mots-cl^s:  Systime  de  Gestion  de  Fichiers,  Systime  de  Gestion  d’Objets,  Base  de  Donnies 
Projet,  Base  de  Donnies  de  Genie  Logiciel. 
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1  Introduction 


Software  development  requires  today  more  sophisticated  supports  than  File  Management 
Systems  (FMS)  could  offer.  Indeed  an  FMS  offers  a  poor  universe  since  it  only  manipulates 
files.  The  use  of  an  FMS  from  a  programming  language  like  Fortran  obliges  the  user  to  describe 
everything  about  the  internal  structure  of  files.  This  remark  leads  us  to  consider  abstractions 
of  files.  Now  we  may  introduce  a  first  definition  of  what  we  will  call  objects: 

A  software  object  is  any  basic  information  manipulated  by  the  programming  envi¬ 
ronment. 

According  to  this  definition,  every  instance  of  a  file  in  the  FMS  is  a  particular  object.  We 
mean  that  every  program  has  its  own  view  of  files.  Tools  manage  their  own  representation  of 
the  information  generally  ignoring  all  other  points  of  view.  This  basic  structure  is  not  suflScient 
for  Advanced  Support  Environments  (ASE)  because  it  doesn’t  allow  processors  to  cooperate  in 
a  simple  way. 

2  From  FMS  to  OMS 


In  the  FMS  supported  by  UNIX,  the  notion  of  object  is  not  commonly  shared  by  the  envi¬ 
ronment.  Nevertheless  UNIX  offers  a  good  basis  for  the  construction  of  Software  Engineering 
Data  Base  (SEDB).  We  mean  that  the  FMS  of  UNIX  tends  to  unify  the  concept  of  file  since  it 
treats  every  entity  as  a  file  (classical  files  but  peripherals  as  well). 

Moreover  some  commands  allow  us  to  extract  some  additional  information  about  files.  Let 
us  look  carefully  at  the  file  command,  file  lists  detaib  about  the  type  of  files.  We  could  call 
this  information  an  attribute  attached  to  a  file  even  thought  it  is  not  explicitly  recorded.  This 
approach  is  more  obvious  if  we  consider  UNIX  tools  such  as  SCCS  which  manipulates  more 
structured  objects  than  FMS  does.  Indeed  in  SCCS,  objects  are  enriched  by  attributes  which 
allow  the  tool  to  know  elaborated  information  about  them.  But  this  knowledge  remains  private 
to  SCCS. 

Now  let  us  look  at  a  step  forward.  An  ASE  needs  a  centralized  data  base  whose  management 
system  manipulates  sophisticated  objects.  Such  systems  are  usually  called  Object  Management 
Systems  or  OMS. 

An  OMS  can  be  considered  as  a  Data  Base  Management  System  (DBMS)  having  some 
knowledge  about  the  objects  it  manages.  An  OMS  has  several  roles: 

1.  It  will  be  responsible  for  all  the  problems  of  communication  between  the  Data  Base  (where 
objects  are  stored)  and  a  working  space  in  which  they  will  be  manipulated,  transformed, 
and  so  on. 

2.  Because  the  OMS  has  some  knowledge  about  the  objects  it  manages,  it  would  be  able  to 
support  specific  actions  beyond  the  classical  management  aspect.  For  instance,  it  would  be 
responsible  for  the  consistency  checking  before  deleting,  updating  or  creating  any  object. 
In  this  case,  consistency  may  not  be  assimilated  as  Data  Base  consistency  checked  by  the 
DB  model  but  as  a  syntactic  and  semantic  control. 

Let  us  simply  consider  the  EMACS  text  editor.  Before  you  stop  a  session  without  saving 
your  text,  EMACS  asks  you  if  you  want  to  save  it.  This  basic  action  is  done  by  the  tool 
itself  in  a  classical  FMS  environment  but  should  be  taken  into  account  by  the  OMS  in 
an  ASE.  In  other  words,  an  OMS  must  offer  the  means  to  express  some  integrity  rules, 
consistency  checks,  and  so  on. 


43-3 


The  Portable  Common  Tool  Environment  (PCTE)  may  be  seen  eis  an  evolution  of  UNIX- 
FMS  towards  this  aim.  In  this  system,  several  kinds  of  objects  are  considered.  PCTE  which 
is  built  on  top  of  an  FMS  ,  introduces  the  concept  of  Object  Management  System.  But  it 
doesn’t  fulfil  all  the  requirements  of  an  OMS.  Indeed  the  OMS  of  PCTE  doesn’t  carry  $emantic 
information  about  the  objects. 

3  Several  kinds  of  OMS 


Several  ASE  under  development  include  an  Object  Management  System.  These  ASE  use 
data  models  which  lead  to  a  common  definition  of  what  should  be  an  OMS. 

3.1  The  PCTE  environment 

From  our  point  of  view,  PCTE  described  in  (PCT85)  is  an  intermediate  step  between  FMS  and 
OMS.  In  the  PCTE  model  we  can  extract: 

•  objects:  they  correspond  to  the  traditional  UNIX  file  concept. 

•  attributes:  they  represent  some  additional  values  attached  to  objects. 

•  relations:  they  express  the  logical  associations  and  dependencies  between  objects. 

In  fact,  the  OMS  of  PCTE  includes  the  SCCS  functionalities  and  moreover  collect  a  lot 
of  information  about  software  development.  On  the  other  hand  the  OMS  of  PCTE  doesn’t 
manage  any  semantic  information  on  objects.  More  precisely  PCTE  allows  the  user  to  link 
various  representations  or  versions  of  objects.  These  objects  are  referred  through  pathnames 
(like  UNIX  ones)  whose  PCTE  checks  the  syntax  according  to  derivation  rules. 

3.2  The  Project  Master  Data  Base:  PMDB 

The  PMDB  system  described  in  [PS85|  aims  at  the  integration  of  a  method  for  the  entire 
Software  Life  Cycle.  The  PMDB  distinguishes  the  following  concepts  (close  to  the  PCTE 
ones); 


•  objects:  components  which  characterize  the  type  of  the  data  which  are  relevant  to  a 
project.  They  are  seen  as  sets  of  data  which  have  same  properties  (software  components, 
resources,  dictionary  for  example).  Objects  might  be  instanciated  with  specific  values. 

•  attributes:  they  express  the  characteristics  of  objects.  Every  instance  of  an  object  has 
proper  attributes. 

•  relations:  they  represent  associations  between  objects.  The  links  between  instances  of 
objects  obey  to  the  relations  between  these  objects.  We  mean  that  if  a  user  wants  to  link 
two  instances  of  objects  then  these  objects  must  be  related. 

In  this  approach  the  model  represents  only  a  schema  which  has  as  main  drawback  to  be 
static.  The  project  skeleton  is  fixed  by  the  structure  of  the  objects  and  the  relations  between 
them  but  it  can’t  evolve  during  the  transactions.  PMDB  only  checks  the  syntax  of  the  project 
structure.  But  except  elementary  type  checking,  it  doesn’t  carry  any  significant  semantics. 
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3.3  The  SPRAC  system 

A  significant  example  of  the  functionalitiea  of  an  OMS  is  shown  in  SPRAC  |FJL*8Sa}  and 
|FJL*8Sbj.  SPRAC  aims  at  the  integration  of  three  consecutive  steps  of  the  Software  Life 
Cycle  (specification,  design  and  implementation  levels).  The  data  model  of  SPRAC  is  organized 
around  three  concepts: 

•  objects:  there  are  three  kinds  of  objects  corresponding  to  three  kinds  of  the  software 
components  (functions  and  abstract  data  types,  algorithms,  modules). 

•  relations;  there  are  two  kinds  of  relations: 

-  the  explicit  relations  correspond  to  classical  links  between  the  objects  such  as  uses, 
isjrepresentedjby,  realizes  .... 

-  the  computed  relations  are  obtained  by  a  calculus  on  the  explicit  relations.  For 
instance: 

The  GDD  relation  corresponds  to  uihat  has  been  done. 

The  AGENDA  relation  corresponds  to  vihat  should  be  done  according  to  a  predefined 
method. 

•  semantic  actions:  actions  associated  with  integrity  rules  (constraints).  They  express 
the  properties  that  the  relations  must  satisfy  and  consequently  maintain  the  consistency 
of  the  Project  Data  Base. 

The  SPRAC  system  treats  semantics  (of  the  supported  languages)  but  the  semantic  actions 
are  not  part  of  the  data  base.  The  latter  look  for  language  elements  inside  objects  and  checks 
their  consistency  with  the  other  objects.  The  OMS  is  not  well  discerned  in  SPRAC  even  thought 
it  is  underlying. 

3.4  The  GRASPIN  Data  Base 

The  model  shown  in  [GSZ*87|  is  based  on  the  object  oriented  approach.  Consequently  it  b 
articulated  around  the  notion  of  classes.  A  class  is  decomposed  into: 

•  A  data  structure  which  corresponds  to  the  implementation  of  the  object  structure. 

•  A  set  of  manipulation  methods  which  express  the  access  interface  of  the  object. 

In  GRASPIN,  the  data  base  schema  is  defined  by  the  description  of  the  classes  called  Lan¬ 
guage  Environment  or  LE.  Each  LB  is  a  description  support  for  a  specific  user’s  language.  These 
classes  are  created  from  a  syntactic  and  semantic  specification  of  the  language. 

The  main  advantage  of  this  approach  is  that  the  OMS  has  a  deep  semantic  knowledge  of 
objects  it  manipulates.  By  example  it  can  store  and  update  an  Abstract  Syntax  Tree  with 
semantic  attributes.  The  RELATION  and  TREE  system  classes  provide  the  means  to  evaluate 
and  propagate  these  attributes  in  the  tree.  So  tools  like  compilers  or  syntax  directed  editors  or 
specialized  checkers  can  be  built  above  GRASPIN  in  an  easy  way. 

Another  interesting  particularity  lies  in  the  object  oriented  interface  because  it  hides  all  the 
implementation  details  to  the  user. 

The  GRASPIN  DB  allows  extensibility  of  the  object  definitions.  Moreover,  due  to  its  se¬ 
mantics  knowledge,  its  model  is  dynamic  because  it  can  evolve  (relations  are  created)  during  a 
session. 
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Definition  of  the  OMS  concept 

A  formal  definition  of  what  might  be  an  OMS  has  been  given  in  [MeySS],  This  definition  is 
not  enough  concerned  by  the  semantic  aspects  supported  by  the  objects  themselves.  Indeed  the 
proposed  model  shows  us  how  the  relations  between  objects  can  be  handled  and  implemented 
but  not  why  (semantic  aspects)  they  have  been  chosen. 

in  |Kra82]  the  author  proposes  a  schematic  model  constituted  of  objects,  relations  and 
operations.  This  model  matches  with  what  we  mean  by  OMS.  Nevertheless  the  model  addresses 
only  the  syntactic  aspects  of  the  objects. 

Thus  we  suggest  the  following  model  to  which  syntax  and  semantics  can  be  attached: 

1.  objects:  objects  are  basic  entities  which  compose  any  software  project.  For  instance 
program  module,  requirements,  documentation  are  software  objects.  They  are  not  supposed 
to  be  atomic  since  they  can  be  decomposed.  By  example  a  part  of  program  module  (such 
as  a  procedure)  can  be  considered  as  an  object  itself.  Objects  are  (classically)  decomposed 
into: 


•  content:  it  supports  information  which  is  significant  for  the  user  and  (unfortunately) 
not  for  the  OMS. 

•  attributes:  they  represent  some  additional  information  about  the  object.  This  allows 
the  OMS  to  knou)  more  about  it.  The  attributes  support  part  of  syntax  and/or 
semantics. 

An  object  may  be  instanciated.  This  means  that  the  user  may  introduce  some  instances 
of  objects  with  specific  values  of  attributes. 

example:  Let  us  look  at  program  modules  in  block  structured  programming  languages. 
First  we  create  the  object  program  module  in  our  OMS. 

•  Its  attributes  are  name,  type,  size,  programming  language,  time  of  last  change  .... 

•  Its  content  is  the  text  of  the  module. 

Now  we  consider  an  instance  of  this  object.  The  function  LOG  returns  the  logarithm  of 
a  real  number. 

•  The  values  of  its  attributes  are  LOG  for  the  name,  function  for  the  type,  500  char¬ 
acters  for  the  size,  source  Pascal  loi  the  programming  language,  1/1/88  for  the  time 
of  last  change  .... 

•  The  content  is  the  source  code  in  Pascal  of  the  function  LOG. 

2.  relations:  they  constitute  the  typed  dependency  links  between  the  objects.  They  con¬ 
tribute  both  to  the  syntax  and  semantics  of  the  software  project. 

example;  The  is.used  relation  links  the  LOG  object  to  all  the  objects  in  which  LOG  is 
used. 

3.  semantic  operations; 

•  constraints:  they  define  the  validity  conditions  on  relations  and  attributes. 

•  actions:  they  are  the  procedures  to  be  applied  when  constraints  are  violated. 


* 
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Operations  are  the  support  for  the  deep  semantics  of  the  software  project  in  the  OMS. 
They  provide  the  mean  to  ensure  the  consistency  of  software  developments. 

example;  If  we  suppose  the  constraint  on  any  declaration  is:  only  backward  reference  can 
exiet  then  we  can  imagine  the  action  forwardjrefertnce.  Whenever  the  user  introduces  a 
module  reference  the  constraint  is  checked.  If  the  constraint  is  satisfied  then  a  tuple  of  the 
is-uaed  relation  is  created.  In  case  of  failure  the  forward-  reference  action  is  performed. 


5  Towards  more  semantics  managed  by  OMS 


We  now  consider  in  more  details  some  examples  of  constraints  (and  the  associated  semantic 
actions]  which  do  exist  in  some  Software  Engineering  Environments. 

5.1  Integrity  rules  in  SPRAC 

In  the  SPRAC  system,  there  are  several  kinds  of  consistency  checks  e.g.  semantic  operations 
[FJL*85b|.  Their  performance  ensures  the  consistency  of  the  Project  Data  Base  (PDB)  in  which 
all  the  software  objects  are  built  and  managed. 

A  first  kind  of  checks  is  done  during  the  compilation  phase,  each  time  a  given  object  is  intro¬ 
duced.  For  instance,  any  object  may  refer  to  other  objects.  The  consistency  check  corresponding 
to  the  import  clause  consists  in  verifying  that; 

•  If  the  referred  objects  exist  in  the  PDB,  then  they  are  consistent  with  their  use.  Consistent 
means  that  name,  arguments  and  tgpes,  interfaces,  . . .  are  valid  both  at  the  level  of  the 
use  and  at  the  level  of  the  declaration.  If  the  test  fails  then  the  introduction  of  the  object 
is  rejected. 

•  If  the  referred  objects  do  not  exist  in  the  PDB,  then  no  checks  are  made.A  predefinition  of 
the  referred  object  is  generated  and  put  in  the  PDB.  The  consistency  check  will  be  done 
when  the  definition  of  the  forward  reference  will  be  completed  later  on. 

Another  example  of  integrity  rule  is  the  introduction  of  laws  corresponding  to  part  of  a 
method  the  programmers  have  to  follow.  In  SPRAC,  there  must  exist  for  any  module  both  a 
specification  and  an  algorithm.  A  law  corresponding  to  a  top  down  development  may  state; 

A  specification  must  be  done  before  the  creation  of  an  algorithm 
and 

an  algorithm  must  exist  before  writting  a  program 

This  two  laws  are  interpreted  as  integrity  rules  by  SPRAC  when  a  new  object  is  given  to  the 
system.  The  application  of  the  two  integrity  rules  may  conduct  to  the  rejection  of  the  object  if 
the  laws  are  not  satisfied.  By  this  way  we  ensure  the  consistency  of  the  PDB  with  respect  to  a 
method. 

The  model  of  the  OMS  supported  by  SPRAC  allows  to  make  such  consistency  checks.  But 
the  consistency  checks  are  isolated  in  many  independent  functions  called  each  time  there  is  a 
need  for  them.  No  real  integration  of  the  semantics  depending  on  the  language  in  which  objects 
are  described  is  taken  into  account  by  the  OMS  of  SPRAC. 


5.2  Integrity  rules  in  B 

The  B  system  [Abi86|  U  a  general  proof  checker  allowing  to  create, delete,  modify  formulas  and 
to  handle  them  with  the  help  of  a  metalogic.  One  of  the  main  interesting  capabilities  of  B  is  its 
ability  to  help  users  create  proofs  (in  the  mathematical  sense).  On  one  hand  we  have  formulas 
organized  as  ’’theories”  (in  which  formulas  represent  either  axioms  or  theorems),  on  the  other 
hand  we  have  proofs.  In  B,  proofs  are  structured  objects.  They  are  trees  in  which; 

•  nodes  support  the  transformed  formula. 

•  arrows  contain  either  a  reference  to  an  applied  transformation  (like  GENERALISATION, 
DEDUCTION,  HYPOTHESIS,  . . . )  or  a  REWRITING  rule  (axiom  or  theorem)  used  for 
the  transformation. 

Some  examples  of  integrity  rules  (corresponding  to  what  is  usual  in  mathematics)  are: 

•  each  time  a  proof  is  under  development,  no  modification  tn  the  used  theories  are  available. 
In  other  words  the  proof  activity  restricts  the  capability  of  the  B  system  from  the  point 
of  view  of  the  DB  aspects. 

■  if  any  formula  (axiom  or  theorem)  is  removed  then  all  the  proofs  using  it  are  removed. 
This  is  a  very  strong  integrity  rule  because  it  can  be  followed  by  the  deletion  of  a  lot 
of  proofs.  A  less  restrictive  one  could  be:  if  any  formula  is  removed  then  all  the  proof 
using  it  are  to  be  replayed.  In  the  latter  the  system  warns  the  user  to  pay  attention  to  the 
validity  of  some  proofs. 

5.3  Need  for  OMS  supporting  integrity  rules 

The  main  conclusion  from  these  examples  of  constraints  (and  consequent  actions)  is  that  in¬ 
tegrity  rules  do  really  exist  but  are  performed  as  separate  functions.  Even  if  they  correspond 
to  a  single  semantic  actions,  they  are  not  gathered  in  a  unique  component. 

This  remark  can  be  extended  to  programming  languages  ranging  from  FORTRAN  to  ADA. 
Indeed  if  we  look  carefully  at  these  languages,  a  problem  such  as  modularity,  clearly  shows  that 
consistency  checks  are  needed.  Depending  on  the  maturity  of  the  considered  language,  different 
levels  of  checks  should  be  available. 

For  instance  in  FORTRAN  no  checks  at  all  are  made,  neither  at  the  compilation  nor  at 
the  run.  On  the  contrary  in  ADA  some  checks  are  performed.  For  instance,  the  USE  clause 
refers  to  objects  (data  or  programs  or  packages)  to  be  imported  in  the  module  where  the  clause 
appears.  But  as  for  SPRAC,  checks  are  made  at  different  times  in  separate  functions. 

The  main  reason  is  there  doesn’t  exist  real  SEDB  but  only  semantic  functions  from  place 
to  place  and  used  in  specific  parts  of  the  system. 

A  SEDB  should  act  at  a  microscopic  level  of  objects  which  is  the  level  of  the  semantics  sup¬ 
ported  by  the  language  in  which  objects  are  described.  In  GRASPIN  [GSZ*87|  this  requirement 
has  been  partially  taken  into  account. 

6  An  example  of  SEDB  in  the  context  of  TOOLUSE 

We  now  introduce  a  Software  Engineering  Data  Base  in  the  context  of  an  under  development 
ASE.  We  first  examine  very  briefly  the  role  of  the  ASE,  then  the  objects  it  manages  and  the 
model  we  have  developed. 
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6.1  The  TOOLUSE  project  and  DEVA,  a  development  language 

The  TOOLUSE  project  |Hoi85]  is  the  continuation  of  the  SPRAC  project.  TOOLUSE  empha¬ 
sizes  the  role  of  methods  in  ASE.  In  other  words,  it  aims  at  producing  the  means  to  express 
software  development  descriptions.  A  development  of  any  piece  of  software  can  be  made  with 
the  help  of  the  development  language  called  DEVA  |SWdGC87].  DEVA  is  a  wide  spectrum 
language  which  allows  to  describe  all  the  components  built  and  used  during  the  software  life 
cycle.  Among  them:  specifications,  developments  and  programs.  The  availability  of  DEVA 
as  development  language  is  the  first  step  for  consideration  of  methods  in  ASE.  Indeed,  using 
DEVA  makes  consider  methods  e.g.  the  ways  software  must  be  developed  according  to  specific 
recommendations  (target  system,  application  area,  company  rules). 

The  structure  of  a  DEVA  program  is  of  the  following  forms: 

•  (A  h  B)  which  can  be  interpreted  as  "from  A  we  can  derive  B”  (inference  rule)  or  the 
program  B  satisfies  the  specification  A  (development  process).  Both  interpretations  are 
valid. 

•  ((A  H  B)  H  C)  which  is  a  more  general  form  and  can  be  interpreted  as  from  A  we  can 
derived  B  according  to  the  proof  C  or  the  development  C  ensures  that  the  program  B 
satisfies  the  specification  A. 

In  this  paper,  we  are  not  considering  DEVA  in  details.  We  will  only  exhibit  how  around 
these  general  structures  ((A  h  B)  or  ((A  I-  B)  H  C)  a  SEDB  has  been  built. 

6.2  The  DEVA  SEDB 

The  semantic  constraints  (other  than  those  ones  ensured  by  classical  DBMS)  are  strongly  related 
to  those  ones  from  SPRAC  and  B.  Indeed  main  of  the  objects  manipulated  with  DEVA  inherit 
from  SPRAC  (software  objects)  and  from  B  (proof  construction).  A  proof  (in  the  sense  of  B) 
is  nothing  more  than  a  development  (in  the  software  development  process  terminology). 

6.3.1  The  SEDB  model 

The  model  we  have  chosen  corresponds  to  the  definition  previously  given.  The  instance  of  this 
model  is  based  on  the  relational  approach.  More  precisely,  we  restrict  our  (instance  of)  model 
to  binary  relations: 

1.  is-object  (ident,  formula) 

which  makes  the  link  between  a  definition  and  an  identifier. 

2.  has-type  (ident,  type-value) 

which  attributes  a  type  to  any  DEVA  object:  specification,  program,  proof,  law,  rewriting 
rule,  ADT,  function, _ 

3.  is-certifUd  (ident,  boolean) 

which  enables  the  system  to  guarantee  an  object  is  valid  or  not. 

4.  is-constructed-by  (ident,  ident) 

which  represents  the  DEVA  schema  (A  h  B)  with  its  meanings.  The  general  schema 

((A  I-  B)  H  C)  is  ternary.  Thus  it  needs  to  be  decomposed  into: 

is-object  (idl,(A  h  B)) 

is-object  (idS,C) 

is-constructed  (idS,idl). 


5.  in-anteeedent-of  (ident,  ident) 

which  gives  the  list  of  dUeet  antecedent  of  the  Ist  argument. 

6 . 

This  model  derived  from  the  definition  of  the  manipulated  objects  is  static.  The  tuples  of 
relations  are  instanciated  at  the  definition  time  (edition  or  compilation). 

Because  the  model  is  directly  implemented  through  binary  relations,  it  is  possible  to  make  it 
dynamic.  By  dynamic  we  mean  the  availability  to  introduce  new  objects  and/or  new  relations. 
Indeed,  in  our  approach,  there  doesn’t  exist  an  OMS  schema  but  only  an  instanciation.  This 
advantage  is  unfortunately  counterbalanced  by  the  need  of  semantic  actions  applied  to  the 
relations  themselves. 

6.3.2  The  SEDB  as  a  main  component  of  TOOLUSE 

The  architecture  of  the  DEVA  support  environment  is  as  represented  in  figure  1. 


figure  1 


The  components  are: 

•  the  MMI  which  enables  the  conversion  from  external  syntax  to  internal  one  (manipulated 
by  the  ASM).  During  the  transformation,  the  syntax  of  the  DEVA  language  is  used  to 
generate  checks  by  calls  to  the  SEDB.  For  instance  as  soon  as  an  object  is  referred  then 
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its  definition  (of  course  if  it  exists)  is  shown  to  the  user.  In  the  same  time  checks  are 
made  about  the  validity  of  the  call 

•  PM  is  a  pattern-matcher  used  for  the  retrieval  of  information  (objects)  either  in  the  Data 
Base  (BD)  or  in  the  Working  Space  (WS).  Any  reference  to  an  object  will  be  translated 
to  a  call  to  the  SEDB  which  in  this  case  performs  the  call  as  a  classical  DBMS. 

•  DED  is  the  deduction  system  which  allows  to  run  DEVA  programs.  Attached  to  it  are  a 
lot  of  semantic  actions  only  performed  at  the  run  time. 

In  this  architecture,  the  first  role  of  the  SEDB  is  a  DBMS  role  e.g.  it  is  called  any  time  an 
operation  needs  the  presence  of  more  information  not  directly  available  within  the  operation. 

The  second  role  is  concerned  with  the  semantics  any  operation  may  require.  For  instance, 
if  an  operation  (supported  by  DED)  consists  of  replaying  a  development  in  a  slightly  modified 
context  (for  a  yet  developed  program)  then  the  SEDB  will  be  responsible  for  checking  the 
availability  of  the  replay  and  in  case  of  success  for  the  certification  of  the  new  development. 

7  Conclusion 


This  paper  presents  the  role  of  an  Object  Management  System  in  the  context  of  Advanced 
Support  Environment.  As  shown  through  several  ASE  under  development  the  OMS  will  consti¬ 
tute  the  kernel  of  the  system,  both  from  the  viewpoint  of  its  DBMS  role  and  from  the  viewpoint 
of  the  integrity  of  the  software  development. 

For  this  purpose  we  suggest  to  regard  a  SEDB  as  supporting  as  much  as  possible  semantics 
of: 

•  the  objects  manipulated.  The  semantics  can  be  deduced  from  the  description  language 
used.  It  is  important  to  notice  that  a  domain  application  language  will  conduct  to  more 
semantics  and  therefore  to  more  constraints. 

•  the  underlying  model  of  software  development.  It  will  be  necessary  to  construct  (by  hand) 
some  specific  relations  and  to  develop  corresponding  semantic  actions. 

The  model  we  have  developed  carries  out  the  precedent  objectives.  The  experimentations 
are  conducted  in  the  context  of  an  ASE  which  is  quite  devoted  to  the  formalization  of  software 
development  in  order  to  replay  some  existing  developments  and  to  adapt  them  to  new  contexts. 
By  this  way,  we  hope  to  be  able  to  favor  the  reuse  of  software. 
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DISCUSSION 


A.O.Waf4,UK 

In  your  REPLAY  system  are  you  replaying  the  human  design  decision  or  the  formal  transformational  steps  (as  happens 
with  REFINE)? 

Author’s  Reply 

In  the  REPLAY  system,  the  sequence  of  transformational  steps  recorded  during  a  development  is  replayed.  DEV  A,  the 
tool  development  language,  formalizes  the  development  by  recording  what  has  been  d'"  ne  during  the  development  but  it 
has  no  way  to  formalize  why  one  transformation  was  better  than  another.  This  is  the  role  of  what  is  called  a 
CONTEXT. 
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ADA  IN  EMBEDDED  AVIONIC  SYSTEMS 
W.  Mansel 

Messerschml  tt  BBIkow  Blohm  GinbH,  Military  Aircraft  Division 
Postfach  80  11  60.  0-8000  MUnchen  80,  West  Germany 


Summary 

Ada  will  be  used  for  real-time  avionic  software  on  the  TORNADO  aircraft  upgrade  programme 
and  on  the  EFA  programme.  For  the  HARM  integration  programme  onto  the  TORNADO  aircraft  an 
Ada  crosscompiler  based  on  the  Karlsruhe  compiler  technology  configured  to  a  multi¬ 
processor  avionic  computer  is  used.  Software  prototyping  has  been  applied  to  gain  ex¬ 
perience  with  Ada  avionics  application.  The  results  will  be  discussed  as  well  as  the 
experience  from  benchmark  tests  on  different  Ada  crosscompiler  systems  for  single  pro¬ 
cessor  MC  68000  and  68080  microprocessor  targets.  Special  emphasis  will  be  taken  on  Ada 
tasking  and  the  parallelism  in  avionic  software. 


1 .  Introduction 

The  avionic  systems  of  modern  military  aircrafts  are  becoming  more  and  more  complex.  This 
is  due  to  the  increasing  complexity  of  expected  battle  field  scenarios  and  consequently 
increasing  complexity  of  tactical  requirements.  To  meet  that  requirements  for  increased 
computing  capacity  and  amount  of  stored  sof tware. distri buted  avionic  systems  have  been 
developed.  The  individual  computers  in  the  onboard  network  have  dedicated  tasks  as  e.g. 
navigation,  cockpit  management  or  weapon  management. 

The  characteristic  features  of  an  avionic  computer  are  1-5  MByte  memory  capacity  and 
1  -  3  MOPS  processing  capacity.  Whereas  that  has  been  achieved  usually  by  bit  slice 
machines  there  is  a  strong  trend  especially  in  Europe  to  use  standard  16  or  38  Bit  micro¬ 
processors.  To  achieve  the  apropriate  processing  throughput, new  avionic  onboard  computers 
are  multiprocessor  architectures  with  2  to  4  microprocessors  and  additional  I/O  pro¬ 
cessors  for  e.g.  STANAG  3838  bus  (MIL  1553)  handling. 

From  the  use  of  standard  microprocessors  there  is  a  major  benefit  for  the  development  of 
avionic  software.  For  the  development  off-the-shelf  tools  as  macro  assemblers  or  compilers 
for  a  large  variety  of  high  order  languages  and  software  development  environments  are 
available.  A  similar  situation  exists  for  software  testing  using  debuggers  and  develop¬ 
ment  systems  including  emulators. 

With  growing  complexity  and  amount  of  avionic  software  there  has  been  the  requirement 
from  the  customer  to  the  avionic  industry  to  use  Ada  as  standard  high  order  language  for 
the  implementation  of  embedded  systems  software,  to  increase  the  reliability,  maintain¬ 
ability  and  reusabi 1 ity,  to  lead  to  a  long  term  reduction  of  development  costs.  This 
paper  discusses  some  aspects  of  software  development  for  multiprocessor  avionic  computers 
with  the  special  emphasis  on  Ada  and  Ada  compiler  systems. 

2.  Software  Partitioning  and  Tasking  Strategies  for  Multiprocessor  Architectures 

The  software  partitioning  and  tasking  strategies  can  not  be  discussed  independently  from 
the  hardware  architectures.  Three  typical  architectures  are  shown  in  Fig.  1.  Example  b 
and  c  where  the  processors  have  local  memory  but  interprocessor  communication  is  achieved 
by  shared  memories  are  typical  for  avionic  computers.  Dedicated  input/output  (I/O)  pro¬ 
cessors  must  have  access  to  data  in  shared  memories.  As  a  consequence  for  architecture  b 
one  of  the  processors  has  to  be  coupled  to  the  I/O  processors  resulting  in  a  master- 
slave  configuration. 

The  software  partitioning  has  the  aim  to  achieve  an  optimum  distribution  of  processor 
loads.  There  are  two  general  strategies; 

a)  The  software  is  designed  without  regard  to  the  target  architecture.  It  is  partitioned 
after  it  has  been  written.  This  so  called  post-partitioning  does  not  consider  any  hard¬ 
ware  or  software  architectural  aspects  during  the  design. 

In  this  case  a  language  is  required  to  express  the  partitioning  of  the  programme  onto 
the  target.  In  addition  the  run-time  cost  of  partitioning  is  hidden  and  time  constraints 
can  not  be  guaranteed. 

b)  The  software  is  designed  with  the  distribution  in  mind.  For  that  socalled  pre-parti¬ 
tioning  a  selected  programme  construct  (e.g.  Ada  library  unit)  is  the  unit  of  parti¬ 
tioning.  The  designer  has  to  obey  certain  restrictions  in  inter-processor  units. 

During  the  partitioning  the  software  has  to  be  separated  into  parts  which  have  to  be  pro¬ 
cessed  in  sequence  (modules)  and  parts  which  can  be  processed  in  parallel  (tasks).  Dne 
module  has  to  be  allocated  to  one  processor,  while  tasks  are  candidates  to  run  in 
parallel  on  different  processors.  However  minimising  the  communication  and  data  exchange 
between  the  different  processors  is  a  mandatory  rule.  The  same  rule  is  also  valid  for  the 
total  number  of  tasks  which  should  be  at  a  minimum.  This  is  a  contradictionary  require¬ 
ment  for  real-time  systems,  where  reduction  of  tasks  in  general  result  in  stronger 
dependencies  of  the  software  parts. 


Also  the  timing  and  synchronisation  between  software  parts  running  on  different  proce* 
ssors  have  carefully  to  be  considered.  The  access  to  I/O  lines  Is  essential  for  embedded 
software.  Since  for  the  multiprocessor  architecture  b  (Fig.  tb)  one  processor  (master)  Is 
connected  to  the  I/O  processors,  the  complete  I/O  handling  has  to  be  centralised  on  the 
master  while  the  slaves  should  be  used  for  data  processing. 

The  Interprocessor  synchronisation  of  software  partitions  is  of  central  interest  for 
multiprocessor  avionic  computers  In  real-time  application  In  embedded  systems.  This  syn¬ 
chronisation  Is  realised  by  using  the  relevant  utility  functions  of  real-time  executive 
kernels  e.g.  the  Ada  run-time  system. 

The  traditional  approach  Is  to  use  a  rigid  scheduling  schema  on  every  processor.  This 
fully  cyclic  solution  reduces  the  number  of  tasks  on  one  processor  to  the  number  of  time 
slots  In  the  system  and  results  In  a  deterministic  timing  behaviour  on  one  processor  and 
is  easy  to  test.  But  this  has  to  be  payed  with  a  more  complex  software  structure  since 
e.g.  exeptlon  handling  due  to  passed  over  timeframes  has  to  be  implemented.  In  addition 
special  packages  for  the  Interprocessor  data  exchange  and  synchronisation  have  to  be  de¬ 
veloped.  In  general  the  rigid  scheduling  schema  will  result  in  a  rigid  software  structure 
which  is  more  difficult  to  adapt  to  later  requirements  and  therefore  unfrinedly  for  main- 
tainance.  This  approach  Is  only  convenient  for  small,  dedicated  systems. 

A  more  adequate  approach  for  complex  real  time  embedded  systems  Is  a  totally  event  and 
priority  driven  system.  This  asynchroneous  solution  which  Is  strongly  supported  by  Ada 
implements  Independent  processes  as  tasks  which  communicate  and  synchronise  by  the  Ada 
rendezvous.  The  task  scheduling  Is  ruled  by  the  task  priorities.  In  general  the  number 
of  tasks  In  a  fully  concurrent  software  Is  larger  as  for  rigid  scheduling.  The  system  Is 
more  difficult  to  test.  However  the  software  system  Is  much  more  flexible  to  later 
changes  to  Implement  new  requirements.  It  Is  easier  to  maintain.  Possible  timing  problems 
due  to  the  Increased  number  of  tasks  can  be  solved  by  appropriate  adjustments  of  task 
priorities  Into  high  priority  tasks  for  the  time  critical  parts  and  low  priority  tasks. 

An  event  and  priority  driven  system  also  fits  well  onto  a  multiprocessor  target,  since 
the  inter-task  communication  handled  by  the  run-time  system  provides  suitable  mechanisms 
for  1 nterprocessor  communication  and  synchronisation. 

On  the  other  hand,  the  Interfaced  system  devices  must  be  flexible  enough,  to  accept  a 
time  Jitter  with  no  loss  of  performance,  so  that  In  a  multitasking  system  the  little 
time-penalty  due  to  contex  switch  of  tasks  (200  usee)  are  tolerable. 

3.  Ada  Compilers  for  Multiprocessor  Targets 

The  options  for  distributing  a  software  package  Implemented  In  Ada  on  to  multiprocessor 
targets  range  between 

-  one  separate  Ada  programme  for  each  processor 

-  one  single  Ada  programme  distributed  across  the  processors. 

The  first  model  can  be  realised  using  off-the-shelf  Ada  crosscompiler  systems.  However  In 
that  case  no  expllcite  Ada  mechanism  Is  available  for  Interprocessor  communication.  Such 
a  model  therefore  requires  the  programmes  to  communicate  with  each  other  via  the  facili¬ 
ties  provided  In  Ada  for  normal  Input/output  devices.  For  embedded  targets  considered 
here,  this  would  be  through  low  level  input/output,  or  even  through  assembler  code  In¬ 
sertions.  The  disadvantages  of  such  an  approach  are  that  the  software  is  Inflexible 
against  changes  In  the  software  partition  which  reduces  reusability  and  ma Inta 1 nabi 1 1 ty . 
In  addition  the  compiler  and  the  language  tools  can  not  be  used  to  check  the  Interfaces 
between  the  programmes. 

The  use  of  off-the-shelf  Ada  crosscompiler  systems  needs  customisation  to  the  target  with 
respect  to  clock  and  time  handling,  host-target  communication  and  protocol,  target  resi¬ 
dent  loader  and  debug  support  and  import  of  foreign  object  code  modules. 

The  second  model  which  requires  a  real  Ada  mul tiprocessor  crosscompiler  has  the  main  ad¬ 
vantages  that 

-  interprocessor  communication  can  be  Implemented  as  inter-tasK  communication  via  the  Ada 
rendezvous.  8y  that  a  unique  task  communication  mechanism  provided  by  the  Ada  compiler 
can  be  used  on  the  multiprocessor  target. 

-  the  interfaces  between  the  software  components  on  the  Individual  processors  can  be 
checked  with  the  Ada  system. 

As  a  result  the  software  structure  becomes  more  flexible  for  redistribution  onto  the  pro¬ 
cessors  of  a  multiprocessor  target  which  strongly  Increases  the  reusability  and  maintain¬ 
ability  which  has  to  be  payed  by  a  more  complex  Ada  system. 

The  general  features  of  a  multiprocessor  Ada  system  are  shown  In  Fig.  2.  Besides  the  ex¬ 
tension  of  the  Ada  run-time  system  to  handle  a  Interprocesscr  rendezvous,  the  essential 
part  of  this  Is  the  builder  tool.  The  builder  has  to  check  the  dependencies  of  the  pro¬ 
gramme  components  and  establishes  from  the  description  of  the  target  architecture  the 
programme  mapping,  which  Is  the  basic  Information  to  be  used  by  the  loader  and  the  target 
debugger. 
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4.  The  TORNADO  Ada  System  for  HARM  Integration 

This  chapter  discribes  an  Ada  System  developed  for  the  HARM  integration  programme  onto 
TORNADO.  The  target  computer  is  a  Motorola  MC  68000  based  multiprocessor  architecture  of 
the  master-slave  type  as  shown  in  Fig.  3.  To  fully  use  the  benefits  of  software  written 
in  Ada  with  respect  to  flexibility  in  software  partitioning  the  requirement  has  been 
placed  onto  the  Ada  compiler  to  support  the  multiprocessor  target  structure  and  allow 
the  distribution  of  a  single  Ada  programme  onto  the  target. 

4.1.  The  Ada  Crosscompiler  System 

The  resulting  Ada  cross  system  developed  by  Systems  Designers  (TAS-2)  comprises  of  the 
following  components  (Fig.  4): 

-  ANSI  Ada  Cross  Compiler  running  on  VAX/VMS 

-  Optimized  Runtime  System  with  real  time  performance  allowing  intra-processor  and  inter- 
processor  rendezvous 

-  Builder/Linker/Loader  System  compising: 

Definition  Tool  to  specify  the  target  configuration  and  the 
ware ; 

Aquisition  Tool  for  the  inclusion  of  assembly  code  units; 

Builder  Tool  for  linking  and  allocation  of  code  to  memories 
Loader  Tool  for  downloading  software  via  RS  232  line 

Target  Debugger  providing  a  user-interface  and  functions  for  symbolic  debugging 

The  Ada  crosscompiler  includes  the  following  features: 

-  Optimized  Ada  tasking  implementation  with  priority-based  preemptive  task  scheduling 

-  Message  passing  package 

-  Set  time  and  date  function 

-  Support  of  MC  68881  coprocessor 

-  Mathematic  packages  providing 

-  floating  point  functions 

-  fixed  point  functions 

-  Input/Output  packages 

-  character  and  string  I/O 

-  discretes  I/O 

-  STANAG  3838  bus  I/O 

4.2.  The  Target  Specific  Packages 

The  target  specific  I/O  packages  are  a  special  feature  of  the  TAS-2  Ada  system.  This 
packages  however  are  crucial  for  embedded  systems,  but  usually  are  not  provided  by  off- 
the-shelf  Ada  target  systems  and  have  to  be  developed  by  the  user. 

Most  I/O  facilities  in  avionic  computers  are  serving  interrupts  and  therefore  need  an 
Interface  to  the  run-time  system,  but  on  the  other  hand  also  interface  to  the  firmware 
which  handles  the  I/O  driver  chip  sets.  Due  to  that  interrelations  it  has  been  decided 
for  the  TAS-2  Ada  system  to  implement  the  I/O  functions  as  run-tiir.e  library  support 
packages  with  assembler  boddies  for  efficiency  reasons,  providing  a  high  level  Ada  inter¬ 
face  to  the  ■ '“r.  This  strategy  can  also  be  extended  to  other  firmware  functions  to  be 
used  by  the  application  software.  The  standardisation  of  the  Ada  interface  to  the  user  of 
target  specific  packages  introduces  a  higher  degree  of  abstraction  into  the  software  for 
embedded  avionic  systems,  thus  again  increasing  reusability  and  maintainability.  This 
strategy  has  also  been  selected  for  Ada  target  systems  to  be  used  within  the  EFA  project. 

4.3.  Architectural  Dependencies 

The  development  of  Ada  compilers  which  fully  support  multiprocessor  architectures  has 
great  advantages  from  the  user  point  of  view,  as  has  been  discussed.  However,  what  are 
the  limitations  when  trying  to  adapt  such  a  product  to  other  multiprocessor  systems? 

TAS-2  was  designed  for  a  special  multiprocessor  target,  shown  in  Fig.  3.  However  it  was 
a  design  goal  to  keep  the  architecture  dependencies  to  a  minimum. 

The  class  of  multiprocessor  architectures  TAS-2  supports  can  be  characterised  by  the 
following  requirements: 

a)  All  processors  must  be  of  the  same  type. 

b)  There  must  be  a  shared  memory  between  any  pair  of  processors  that  need  to  communicate. 

c)  There  must  be  an  Interrupt  facility  between  any  pair  of  processors  that  need  to  commu¬ 
nicate.  Interrupts  must  be  possible  in  both  directions. 

d)  The  shared  memory  must  be  seen  at  the  same  address  from  the  sharing  processors. 

e)  There  must  be  a  (large  enough  portion  of)  local  memory  which  is  seen  at  the  same 
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address  from  the  various  processors  (a  sufficient  condition  Is  that  the  local  memories 
of  each  processor  are  seen  at  the  same  address), 
f)  A  single  shared  memory  address  must  correspond  to  only  one  memory  location  across  the 
entire  system. 

For  examples  that  fall  Into  this  class  of  architectures,  see  Fig.  1. 

5.  Ada  Software  Structure  for  a  Multiprocessor  Target 

A  typical  example  of  the  operational  software  for  an  embedded  avionic  system  for  a  3-pro- 
cessor  target  of  master-slave  structure  (extension  of  Fig.  3  to  2  slaves)  Is  outlined  In 
Fig.  5.  The  software  Is  structured  Into  four  major  categories  of  software  packages: 
Packages  for  1/0  data  handling,  control  packages  and  calculation  packages  with  high  and 
medium  priorities  and  low  priority  background  packages. 

The  operations  Imported  from  an  I/O-package  enter  the  data  from  pilot  control  pannels  or 
from  sensors  via  a  STANAG  3838  bus.  Depending  on  the  data  entered  from  the  pilot  control 
pannels  control  package  operations  select  the  function  Imported  from  the  calculation 
package  to  be  processed.  The  processed  data  are  transferred  via  the  STANAG  3838  bus  to 
other  subsystems.  As  can  be  seen  from  Fig.  5  the  I/O  packages,  the  control  packages  and 
the  calculation  packages  represent  parallel  tasks  on  different  processors  of  the  multi¬ 
processor  avionic  computer. 

In  the  event  that  this  model  of  an  avionic  software  Is  implemented  In  Ada,  all  tasks  will 
communicate  In  terms  of  the  Ada  rendezvous.  Since  avionic  software  Is  time  critical,  it 
can  not  be  tolerated  that  any  controlling  task  Is  blocked  as  a  consequence  of  Its  entry 
call  to  an  associated  calculation  task  until  the  rendezvous  with  this  task  Is  completed. 
Therefore  the  Ada  rendezvous  concept  enforces  the  Introduction  of  additional  buffer  tasks 
for  deblocking  the  control  and  the  processing  tasks,  as  can  be  seen  from  Fig.  5. 

6.  Conclusions 

Several  aspects  uf  software  design  strategies  for  multiprocessor  avionic  computers  have 
been  discussed  with  the  special  emphasis  on  Ada  and  Ada  compilers.  It  has  been  snown  that 
there  are  encouraging  arguments  for  the  development  of  multiprocessor  Ada  systems.  The 
use  of  such  Ada  crosscompiler  systems  for  the  development  of  avionic  software  is  bene¬ 
ficial  to  exploit  the  concepts  Inherent  In  Ada  and  to  achieve  the  expected  long  term  im¬ 
provement  In  maintainability  and  reusability.  That  arguments  seem  to  justify  the  addi¬ 
tional  development  effort  In  excess  to  the  use  of  off-the-shelf  Ada  crosscompiler  systems 
for  single  processor  targets. 


Fig,  i:  Three  typical  multiprocessor  architectures 
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Fig.  2:  Functional  structure  of  a  multiprocessor  Ada  compiler  system 
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Fig.  4a:  Ada  cross  development  environment  for  the 
HARK  integration  prograrmfe 


Fig.  4b:  Ada  cross  development  environment  for 
the  HARM  integration  progranwe  (cont.) 


Fig.  5;  Ada  software  structure  for  a  multiprocessor  target 
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DISCUSSION 

M.Pitarys,  US 

1 .  What  was  your  requirement  for  the  time  it  takes  to  perform  an  Ada  rendezvous? 

2.  Do  you  implement  a  shareable  run-time  system? 

AuChor*s  Reply 

1.  500  microseconds 

2.  No 
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14.  Abstract 


Software  Engineering  has  evolved  rapidly  but  the  gap  between  demand  and  software  output 
continues  to  grow.  By  the  end  of  the  decade  research  programmes  in  North  America,  Europe 
and  Japan  will  begin  to  produce  results  in  the  areas  of  software  tools,  computer  architecture,  etc. 
The  symposium  considered  how  these  advances  might  be  applied  to  the  avionics  systems  of  the 
nineties  and  beyond  and  their  impact  on  our  aspirations  in  areas  such  as  operation,  fault 
tolerance  etc.  The  software  element  of  modem  weapon  systems  continues  to  grow  in  size  and 
complexity;  offering  major  advantages  but  also  potential  risks. 


